Reputation: 177
We have a recipe in our mobile application, this recipe has a details screen and the details screen has a lot of information, for example:
So is that right to return all this info in the same endpoint or create multiple endpoints for each section?
One endpoint example:
GET: https://www.example.com/api/v1/{recipeId}
Multiple endpoints example:
GET: https://www.example.com/api/v1/{recipeId}/info // this API will return all info including the ingredients
GET: https://www.example.com/api/v1/{recipeId}/rating
GET: https://www.example.com/api/v1/{recipeId}/related
GET: https://www.example.com/api/v1/{recipeId}/nutritional
Upvotes: 0
Views: 1467
Reputation: 1133
It depends.
If a consumer of your API is say a web page where you want to display all the information at the same time in one click, you can just bring all information together and display in one go rather than calling APIs one by one and then aggregating, however if there is possibility that individual endpoints are also required to be called separately, then you can expose multiple endpoints.
Also,your resource uri should be like this :
/api/v1/recipes/{recipeId}
Upvotes: 1
Reputation: 538
In this case, you can create a single API endpoint. And, can expose a query parameter which shows which are the fields user (rest client, web) is interested in.
/api/v1/recipes/{recipeId}/?fields=all
/api/v1/recipes/{recipeId}/?fields=info,rating,related
/api/v1/recipes/{recipeId}/?fields=info
In this way, you will be saved from the headache of writing multiple endpoints for a single serving type. Also, the schema of output message or JSON will be the same.
Maybe in future, you want to add another field to your response. You just need to add another filter name. Your client (web/rest) doesn't need to use a new API for that. Just pass the new filter and done.
Upvotes: 0