fix: Resource list with filter endpoint#365
Conversation
WalkthroughThe changes introduce a new API feature that defines a GET endpoint for retrieving filtered resources by workspace. A TypeScript file now provides an OpenAPI specification for this endpoint, while a corresponding route file implements the GET method with a limit on the number of resources returned. Additionally, the Changes
Sequence Diagram(s)sequenceDiagram
participant C as Client
participant A as API Endpoint
participant M as Auth Middleware
participant DB as Resource Database
C->>A: GET /workspaces/{workspaceId}/resources/{filter}
A->>M: Validate authentication/authorization
M-->>A: Return auth status
A->>DB: Query resources using filter with limit
DB-->>A: Return resource list or error
A-->>C: JSON response (200 on success, 400 on error)
Possibly related PRs
Suggested reviewers
Poem
📜 Recent review detailsConfiguration used: .coderabbit.yaml 📒 Files selected for processing (3)
🚧 Files skipped from review as they are similar to previous changes (3)
⏰ Context from checks skipped due to timeout of 90000ms (3)
🪧 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 using PR comments)
Other keywords and placeholders
Documentation and Community
|
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (3)
apps/webservice/src/app/api/v1/workspaces/[workspaceId]/resources/[filter]/route.ts (1)
24-25: Consider adding try/catch for JSON parsing.While the overall implementation is solid, JSON.parse can throw exceptions for malformed JSON inputs. Consider wrapping this in a try/catch block to handle potential parsing errors more gracefully.
- const filterJson = JSON.parse(params.filter); - const parseFilterResult = resourceCondition.safeParse(filterJson); + try { + const filterJson = JSON.parse(params.filter); + const parseFilterResult = resourceCondition.safeParse(filterJson); + if (parseFilterResult.error != null) + return NextResponse.json( + { error: parseFilterResult.error.message }, + { status: httpStatus.BAD_REQUEST }, + ); + + const { data: filter } = parseFilterResult; + // ...rest of the function + } catch (error) { + return NextResponse.json( + { error: "Invalid JSON format for filter" }, + { status: httpStatus.BAD_REQUEST }, + ); + }apps/webservice/src/app/api/v1/workspaces/[workspaceId]/resources/[filter]/openapi.ts (1)
32-35: Consider adding a more detailed resource schema reference.The current implementation references the Resource schema, but it might be helpful to explicitly document the most important properties of a resource in the description or add a more detailed schema.
openapi.v1.json (1)
2465-2470: Consider adding required field to error response schema.The error response schema for the 400 status code doesn't specify that the "error" property is required. For consistency with other error responses in the API, consider adding the "required" field.
"properties": { "error": { "type": "string" } } + "required": [ + "error" + ]
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
apps/webservice/src/app/api/v1/workspaces/[workspaceId]/resources/[filter]/openapi.ts(1 hunks)apps/webservice/src/app/api/v1/workspaces/[workspaceId]/resources/[filter]/route.ts(1 hunks)openapi.v1.json(51 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
`**/*.{ts,tsx}`: **Note on Error Handling:** Avoid strict en...
**/*.{ts,tsx}: Note on Error Handling:
Avoid strict enforcement of try/catch blocks. Code may use early returns, Promise chains (.then().catch()), or other patterns for error handling. These are acceptable as long as they maintain clarity and predictability.
apps/webservice/src/app/api/v1/workspaces/[workspaceId]/resources/[filter]/route.tsapps/webservice/src/app/api/v1/workspaces/[workspaceId]/resources/[filter]/openapi.ts
⏰ Context from checks skipped due to timeout of 90000ms (3)
- GitHub Check: Typecheck
- GitHub Check: Lint
- GitHub Check: build (linux/amd64)
🔇 Additional comments (10)
apps/webservice/src/app/api/v1/workspaces/[workspaceId]/resources/[filter]/route.ts (4)
1-12: Clean imports with good organization.The imports are well-organized with a clear separation between external dependencies, internal schemas, and application-specific imports. This makes the code easier to maintain and understand.
13-21: Well-structured authentication and authorization middleware.The route correctly implements authentication and authorization middleware, ensuring that users have the proper permissions to list resources within the specified workspace. The middleware pattern is clean and follows best practices for handling API endpoints.
22-30: Good error handling for filter parsing.The code properly parses the filter parameter from JSON and handles invalid filter formats by returning a BAD_REQUEST response with an appropriate error message. This ensures that malformed requests are rejected with clear error feedback.
31-44: Clean database query implementation.The database query correctly combines multiple conditions using the
andoperator to filter resources by both workspace ID and the provided filter criteria. The implementation is concise and follows good practices for database queries.apps/webservice/src/app/api/v1/workspaces/[workspaceId]/resources/[filter]/openapi.ts (3)
1-6: Clean OpenAPI specification setup.The OpenAPI metadata is properly defined with appropriate version and title information, following the OpenAPI 3.0.0 standard.
7-26: Well-defined parameters for the endpoint.The endpoint parameters are clearly specified with proper descriptions, required flags, and schema types. Both the workspaceId and filter parameters are marked as required path parameters with appropriate descriptions.
27-50: Complete response specification.The response schemas are well-defined for both successful (200) and error (400) cases, making the API contract clear for consumers. The success response returns an array of resources, while the error response includes an error message.
openapi.v1.json (3)
2421-2476: Well-defined new endpoint for filtered resources.The new endpoint
/v1/workspaces/{workspaceId}/resources/{filter}is properly defined with clear parameter specifications and response schemas. It maintains consistency with the OpenAPI TypeScript definition and follows the pattern established by other endpoints in the API.
45-47: Improved formatting of required fields for better readability.The "required" fields have been reformatted from single-line arrays to multi-line arrays throughout the file. This improves readability and maintains consistent formatting across the API definition.
Also applies to: 90-92, 108-110, 152-154, 170-172, 188-190, 206-208, 278-282, 313-316, 332-334, 380-382, 420-423, 504-506, 671-675, 698-702, 740-742, 758-760, 862-864, 1130-1134, 1185-1190, 1206-1208, 1224-1226, 1245-1248, 1264-1266, 1324-1328, 1392-1396, 1408-1411, 1469-1471, 1645-1647, 1774-1776, 1804-1806, 1833-1835, 1853-1856, 2191-2195, 2248-2252, 2264-2266, 2559-2564, 2826-2830, 2858-2863, 3073-3079, 3100-3105, 3224-3230, 3234-3237, 2761-2765, 2779-2782, 2785-2788, 2791-2793, 2972-2975, 2980-2984, 3006-3009
993-995: Added tags for better API organization.The "Resource Relationships" tag has been added to the createResourceToResourceRelationship operation. This improves API documentation organization, making it easier for developers to find related endpoints.
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
apps/webservice/src/app/api/v1/workspaces/[workspaceId]/resources/[filter]/route.ts (1)
45-51: Consider differentiating between error types in the catch block.While the current error handling distinguishes between Error objects and other types, consider using different HTTP status codes for different error scenarios instead of using BAD_REQUEST for all errors.
catch (error) { return NextResponse.json( { error: error instanceof Error ? error.message : "Unknown error" }, - { status: httpStatus.BAD_REQUEST }, + { + status: error instanceof SyntaxError + ? httpStatus.BAD_REQUEST + : httpStatus.INTERNAL_SERVER_ERROR + }, ); }
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
apps/webservice/src/app/api/v1/workspaces/[workspaceId]/resources/[filter]/route.ts(1 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
`**/*.{ts,tsx}`: **Note on Error Handling:** Avoid strict en...
**/*.{ts,tsx}: Note on Error Handling:
Avoid strict enforcement of try/catch blocks. Code may use early returns, Promise chains (.then().catch()), or other patterns for error handling. These are acceptable as long as they maintain clarity and predictability.
apps/webservice/src/app/api/v1/workspaces/[workspaceId]/resources/[filter]/route.ts
⏰ Context from checks skipped due to timeout of 90000ms (3)
- GitHub Check: Typecheck
- GitHub Check: Lint
- GitHub Check: build (linux/amd64)
🔇 Additional comments (4)
apps/webservice/src/app/api/v1/workspaces/[workspaceId]/resources/[filter]/route.ts (4)
1-12: LGTM! All necessary imports are present.The imports are well-organized with a clear separation between external dependencies, internal DB/validation modules, and application-specific middleware.
13-21: Good implementation of authentication and authorization middleware.The route appropriately uses authentication and applies proper authorization checks ensuring that users can only access resources they have permission to view. The authorization is correctly scoped to the workspace identified in the URL parameters.
22-32: Good validation of input parameters.The endpoint properly handles parsing of the JSON filter parameter and validates it against a schema. The error handling for invalid JSON input is appropriate, returning a BAD_REQUEST with a clear error message.
33-44: LGTM! Well-structured database query.The database query is well-constructed, combining the workspace ID filter with the dynamic resource metadata conditions. The use of
and()with the workspace equality check ensures resources are properly scoped to the specified workspace.
Summary by CodeRabbit
New Features
Bug Fixes
Documentation