'REST Api Design - Opinion on a design choice
I have an API that is connected to a database and where I retrieve data. One schema example:
The idea is to retrieve all related data based on the Application Primary Key like this:
/Application
/Application/{ID}
/Category
/Category/{ApplicationID}
I have many other tables that have foreign keys to the Application table, so based on the Application Primary Key I can get all related data. Would this be an acceptable approach?
Solution 1:[1]
"REST" is the architectural style on which the HTTP protocol was built. Every web page was intended to be "RESTful" and REST itself says nothing about what the API should look like. The query is obviously about modern APIs. A modern API MUST adhere to the RFCs and at the same time SHOULD adhere to common conventions. Common conventions make the REST API understandable to consumers. Further, I am answering with respect to modern APIs.
API design should be based on the needs of the consumers and not on what you have in the database. Using a PK from a database as a key in a REST API can have many risks (security, evolution, versioning).
The easiest way to create an unusable API with respect to your requirements is:
/applications
/applications/{id}
/categories
/categories/{id}
You can filter categories as well:
/categories?applicationId={id}
You can provide CRUD operations for every resource.
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow
Solution | Source |
---|---|
Solution 1 | Miroslav Holec |