Migrate from generig data route into a restful one #34
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- Add support for GET and POST requests - Implement filtering, sorting, and pagination for GET requests - Handle creation of new headlines via POST request - Utilize DataRepository for data operations - Return appropriate responses using ResponseHelper
- Implement middleware for headlines route in Dart Frog API - Include authentication and authorization checks - Provide model configuration and resource name for context
- Add GET, PUT, and DELETE handlers for individual headlines - Implement request validation and error handling - Use DataRepository for data operations - Return appropriate HTTP responses for each operation
- Add model configuration provider for headline - Implement authorization middleware - Require authentication for headline routes
- Add GET endpoint for retrieving a list of countries (/api/v1/countries) - Add GET endpoint for retrieving a single country by ID (/api/v1/countries/[id]) - Implement middleware for authentication and authorization - Add support for filtering, sorting, and pagination in the countries list endpoint
- Add middleware for /api/v1/dashboard/summary route - Implement GET request handler for dashboard summary - Introduce DashboardSummaryService for business logic
- Remove unused imports in middleware files - Simplify permission checking in headlines endpoint - Implement more granular permission checks based on HTTP method - Remove unused PermissionService import
- Add middleware for authentication and authorization - Implement GET endpoint for languages collection with filtering, sorting, and pagination - Implement GET endpoint for single language by ID
- Add GET, POST, and PUT handlers for remote-configs - Implement collection and singleton resource endpoints - Add middleware for authentication and authorization - Update DataRepository to support RemoteConfig type
- Add GET, POST, PUT, and DELETE handlers for /api/v1/sources - Implement filtering, sorting, and pagination for GET requests - Add middleware for authentication and authorization - Create Source model and DataRepository<Source>
- Add GET, POST, PUT, and DELETE handlers for /api/v1/topics - Implement filtering, sorting, and pagination for GET requests - Add middleware for authentication and authorization - Use DataRepository for data access - Return appropriate HTTP statuses and JSON responses
- Add GET, PUT, and DELETE handlers for individual user items - Implement GET handler for user collection with filtering, sorting, and pagination - Create middleware for authentication and authorization - Use DataRepository for user data access - Implement response helper for consistent API responses
- Add GET and PUT endpoints for user content preferences - Add GET and PUT endpoints for user app settings - Implement middleware for authentication and authorization - Include business logic for validating preference limits
- Remove model-specific access rules and route-group specific logic - Focus on role-based permissions only - Reduce middleware responsibilities and increase flexibility
- Renamed `ownershipCheckMiddleware` to `userOwnershipMiddleware` for clarity - Removed unnecessary dependencies and simplified middleware logic - Removed model-specific checks and focused on user ID comparison - Updated documentation to reflect simplified functionality
- Add ownership check middleware to user, preferences, and settings endpoints - Remove duplicate authentication and authorization logic - Simplify middleware implementation using a shared ownership check function
- Deleted the entire _middleware.dart file in the headlines route - This file was likely no longer needed, as its functionality might have been replaced or moved elsewhere
- Clarify that countries data is static and read-only for authenticated users - Explain that modifications are not allowed via the API - Mention that the data is managed by database seeding
- Remove unnecessary item request check for GET method - Use Permissions.headlineRead for all GET requests - Add comment for default case - Improve code readability and maintainability
- Clarify that languages data is static and read-only for all authenticated users - Emphasize that modification via API is not allowed - Mention that language data is managed through database seeding in real-world scenarios
- Add a comment explaining that sources are managed by admins but readable by all authenticated users - Improve code readability and maintainability
Add a comment to explain that topics are managed by admins but readable by all authenticated users.
- Separate middleware responsibilities for better clarity and maintainability
- Enhance permission checking logic for /users and /users/{id} routes
- Disallow user creation through /users route, redirecting to /auth routes
- Optimize middleware order for improved security and performance
- Add authentication and authorization checks - Implement permission-based access control - Support for GET and PUT requests with specific permissions - Return 405 Method Not Allowed for unsupported request methods
- Add authentication and authorization checks - Implement permission-based access control
…g endpoint - Merge remote-configs and remote-configs/[id] endpoints into a single remote-config endpoint - Update middleware to reflect singleton resource constraints - Modify handler to use a well-known ID for the singleton remote config document - Remove collection operations (GET all, POST) as they are no longer applicable - Update API documentation to reflect changes
- Remove unused import of ModelRegistryMap - Remove unused provider of ModelRegistryMap in middleware function
- Rename generic DATA API rate limit settings to more specific READ and WRITE limits - Increase default READ limit from 1000 to 5000 requests per hour - Set default WRITE limit to 500 requests per hour - Update comments to clarify the purpose of each rate limit setting
- Lower default READ rate limit from 5000 to 500 requests per hour - Reduce default WRITE rate limit from 500 to 50 requests per hour - These changes provide a more restrictive starting point for rate limiting, which can help protect against abuse while still allowing for reasonable usage.
…tions - Rename `rateLimitDataApiLimit` to `rateLimitReadLimit` and adjust default value - Rename `rateLimitDataApiWindow` to `rateLimitReadWindow` - Add new `rateLimitWriteLimit` and `rateLimitWriteWindow` configurations - Update parameter names and comments for clarity
- Add configured_rate_limiter.dart with implementations for rate limiting - Introduce role-aware rate limiter that respects bypass permissions - Provide pre-configured rate limiters for READ and WRITE operations - Use authenticated user's ID as the key for rate limiting
- Add rate limiting middleware to all headline endpoints - Implement separate rate limiters for read and write operations - Update middleware documentation to reflect new rate limiting functionality
- Add rate limiting to the countries API routes - Implement read rate limiting for GET requests - Update middleware to include rate limiting functionality - Import configured_rate_limiter for rate limiting capabilities
- Removed break statements after setting rateLimiter in switch case - This change simplifies the code structure and improves readability
- Add rate limiting to GET requests for languages endpoint - Import configured_rate_limiter package - Update middleware documentation to reflect new rate limiting feature - Implement rate limiter in the request handling pipeline
- Add rate limiting to GET and PUT requests - Introduce configured_rate_limiter middleware - Update middleware chain to apply rate limiting before authorization
- Add rate limiting middleware for all sources endpoints - Implement separate rate limiters for read and write operations - Update middleware documentation to reflect new rate limiting feature
- Add rate limiting middleware to topics route - Implement separate rate limiters for read and write operations - Update middleware to use rate limiter for non-GET requests
- Add `configured_rate_limiter` import to middleware dependencies - Refactor `permissionSetter` to `rateAndPermissionSetter` to include rate limiting - Apply rate limiting to GET, PUT, and DELETE requests on users endpoints - Update middleware documentation to reflect new rate limiting functionality
- Add configured_rate_limiter import to apply rate limiting - Update middleware chain to include rate limiting for different HTTP methods - Refactor _permissionSetter to _rateAndPermissionSetter to incorporate rate limiting - Apply read and write rate limiters based on the HTTP method
- Add configured_rate_limiter import for rate limiting functionality - Implement rate limiting in the user settings middleware chain - Update middleware documentation to reflect new rate limiting step - Modify _rateAndPermissionSetter function to handle rate limiting and permission setting
- Remove outdated information about managing core news data
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Summary of Changes
Hello @fulleni, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!
I've undertaken a significant refactoring effort to migrate the API from a generic data route to a more structured and explicit RESTful design. This change involves creating dedicated endpoints for each data model, simplifying middleware logic, and introducing more granular rate limiting. The goal is to enhance the API's clarity, maintainability, and scalability by aligning it more closely with standard REST architectural principles.
Highlights
- API Restructuring to Dedicated RESTful Endpoints: The core of this PR is a complete overhaul of the API structure, moving away from a single, generic
/api/v1/dataendpoint that relied on a?model=query parameter. Instead, I've introduced dedicated, more intuitive RESTful endpoints for each resource, such as/api/v1/headlines,/api/v1/topics,/api/v1/users, and more. This significantly improves API clarity, maintainability, and adherence to REST principles. - Simplified and Specialized Middleware Logic: I've refactored the authorization and ownership check middlewares. The
authorizationMiddlewareis now simpler, as permissions are explicitly provided by route-specific middleware rather than being dynamically determined from aModelRegistry. Similarly, theownershipCheckMiddlewarehas been streamlined and renamed touserOwnershipMiddleware, focusing specifically on user-owned resources. - Granular Read/Write Rate Limiting: New rate limiting configurations have been introduced, allowing for separate limits for read and write operations. These are now configurable via distinct environment variables (
RATE_LIMIT_READ_LIMIT,RATE_LIMIT_WRITE_LIMIT, etc.). A newconfigured_rate_limiter.dartfile encapsulates this logic, including the ability for privileged users to bypass rate limits. - Removal of Generic Model Registry: The
model_registry.dartfile, which was central to the old generic data route's operation, has been completely removed. This simplifies the codebase and eliminates a layer of abstraction no longer needed with the new dedicated endpoint approach. - Introduction of Numerous New Dedicated Route Files: A substantial number of new route files have been added under
routes/api/v1/to support the new dedicated endpoints for various resources, including countries, dashboard summaries, headlines, languages, remote configurations, sources, topics, and user-specific data (profiles, preferences, and settings). Each new route includes its own middleware for specific authentication, authorization, and rate limiting rules.
Using Gemini Code Assist
The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.
Invoking Gemini
You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.
| Feature | Command | Description |
|---|---|---|
| Code Review | /gemini review |
Performs a code review for the current pull request in its current state. |
| Pull Request Summary | /gemini summary |
Provides a summary of the current pull request in its current state. |
| Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in issue comments and review comments. |
| Help | /gemini help |
Displays a list of available commands. |
Customization
To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.
Limitations & Feedback
Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments or fill out our survey to provide feedback.
You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.
Footnotes
-
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩
There was a problem hiding this comment.
Code Review
This pull request represents a significant and well-executed architectural refactoring, migrating the API from a single generic /data endpoint to a more robust and maintainable RESTful design with dedicated routes for each resource (e.g., /headlines, /users, /topics). This change greatly improves the clarity, scalability, and adherence to API best practices. The removal of the complex ModelRegistry and the introduction of cleanly-scoped middleware for authentication, authorization, and rate-limiting are excellent improvements. My review found a couple of minor documentation typos in the new environment configuration, but overall, this is a very strong and positive change for the project.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Status
READY/IN DEVELOPMENT/HOLD
Description
Type of Change