fix: Use subrouter for API and correctly handle 404 errors #105
Conversation
Currently, the implementation for API v1 routes has the main drawback that any unknown path gets the fallback `notFoundHandler`, trying to access filesystem paths. However, for API routes specifically, we can have a subrouter, and a default NotFound handler that returns 404. With this change, requests to `api/v1/<unknown>` now correctly returns status code 404 instead of 200.
WalkthroughWalkthroughThe changes involve a significant restructuring of the API's routing logic in the Changes
Sequence Diagram(s)sequenceDiagram
participant Client
participant API Gateway
participant Route Handler
participant Controller
Client->>+API Gateway: Request to /v1/status
API Gateway->>+Route Handler: Direct to Status Handler
Route Handler->>Controller: Fetch status data
Controller-->>Route Handler: Status data
Route Handler-->>-Client: Status Response
Client->>+API Gateway: Request to /v1/reporting/bill-of-materials
API Gateway->>+Route Handler: Direct to Reporting Handler
Route Handler->>Controller: Fetch Bill of Materials
Controller-->>Route Handler: Bill of Materials data
Route Handler-->>-Client: Reporting Response
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (invoked as PR comments)
Additionally, you can add CodeRabbit Configration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files selected for processing (2)
- backend/app/api/handlers/v1/controller.go (1 hunks)
- backend/app/api/routes.go (2 hunks)
Files skipped from review due to trivial changes (1)
- backend/app/api/handlers/v1/controller.go
Additional comments not posted (20)
backend/app/api/routes.go (20)
59-64: Initialization of API version 1 routing.The initialization of API version 1 routing looks correct and sets the foundation for subsequent route definitions.
66-66: Initialization of currency handler.The initialization of the currency handler is straightforward and follows the pattern established in the previous segment.
68-70: Definition of authentication providers.The definition of authentication providers is clear and concise, utilizing the
NewLocalProviderfunction.
72-73: User registration and login endpoints.The user registration and login endpoints are correctly defined and utilize the appropriate handlers.
75-78: Middleware for user-related endpoints.The middleware setup for user-related endpoints ensures proper authentication and role checks.
80-86: User-related endpoints.The user-related endpoints are correctly defined, covering various user actions such as self-management and authentication.
88-93: Group-related endpoints.The group-related endpoints are correctly defined, covering various group actions and statistics.
98-101: Action-related endpoints.The action-related endpoints are correctly defined, covering various actions related to assets and items.
103-108: Location-related endpoints.The location-related endpoints are correctly defined, covering various actions related to locations.
110-114: Label-related endpoints.The label-related endpoints are correctly defined, covering various actions related to labels.
116-127: Item-related endpoints.The item-related endpoints are correctly defined, covering various actions related to items, including creation, import, export, and management of custom fields.
129-131: Item attachment endpoints.The item attachment endpoints are correctly defined, covering creation, update, and deletion of attachments.
133-136: Item maintenance endpoints.The item maintenance endpoints are correctly defined, covering various actions related to maintenance logs.
138-138: Asset retrieval endpoint.The asset retrieval endpoint is correctly defined and utilizes the appropriate handler.
140-145: Notifier-related endpoints.The notifier-related endpoints are correctly defined, covering various actions related to user notifiers.
147-151: Middleware for asset-like endpoints.The middleware setup for asset-like endpoints ensures proper authentication and role checks.
153-157: Asset-like endpoints for QR code generation and item attachments.The asset-like endpoints for QR code generation and item attachments are correctly defined and utilize the appropriate handlers.
159-159: Reporting services endpoint.The reporting services endpoint for bill of materials export is correctly defined and utilizes the appropriate handler.
162-162: Addition of default NotFound handler.The addition of a default
NotFoundhandler ensures that unknown API paths return a 404 status code, improving the API's robustness.
162-162: Ensure correct handling of 404 errors.The
r.NotFound(http.NotFound)line ensures that the correct 404 handler is used for unknown API paths, aligning with the PR's objective.
What type of PR is this?
What this PR does / why we need it:
Currently, the implementation for API v1 routes has the main drawback that any unknown path gets the fallback
notFoundHandler, trying to access filesystem paths.However, for API routes specifically, we can have a subrouter, and a default NotFound handler that returns 404.
Testing
With this change, requests to
api/v1/<unknown>now correctly returns status code 404 instead of 200.Summary by CodeRabbit
New Features
/reporting/bill-of-materials.Improvements
/v1for better organization.NotFoundhandler for undefined routes.