The current API model stores only the basic information required to publish an API.
As platform grows, API consumers may benefit from additional metadata such as:
- Category
- Version
- Documentation URL
- Contact Information
- Website
- License
- Tags
- Visibility
- Total Subscribers
- Ratings and reviews ( future )
The current schema does not provide enough flexibility for these features.
Proposed Solution
Investigate the best approach for extending the API metadata.
Possible approach include:
- Extending the existing 'apis' table.
- Creating dedicated tables for related metadata.
- Any alternative design that keeps the database maintainable
- and scalable.
Contributors are encouraged to discuss the trade-offs before implementation.
Acceptance Criteria
- The new design is documented and easy to understand.
- Existing functionality continues to work.
- Database Migrations are handled through flyway.
- ERD is updated to reflect schema changes.
- API documentations is updated where necessary.
The current API model stores only the basic information required to publish an API.
As platform grows, API consumers may benefit from additional metadata such as:
The current schema does not provide enough flexibility for these features.
Proposed Solution
Investigate the best approach for extending the API metadata.
Possible approach include:
Contributors are encouraged to discuss the trade-offs before implementation.
Acceptance Criteria