Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
Post History
This is based on a code review discussion that I had with a colleague about the way I have designed the resources paths for an ASP.NET Core controller that is currently consumed only internally (by...
#2: Nominated for promotion
by
Alexei
·
2022-02-13T11:37:51Z (almost 3 years ago)
#1: Initial revision
by
Alexei
·
2022-01-07T14:49:10Z (almost 3 years ago)
Using nested paths vs. flat ones for API resources
This is based on a code review discussion that I had with a colleague about the way I have designed the resources paths for an ASP.NET Core controller that is currently consumed only internally (by a SPA).
The paths were flattened (e.g. GET /api/productreview/{reviewId}) and my colleague argued that they should be nested (e.g. GET /api/product/{productId}/review/{reviewId}.
My rationale for choosing the "flattened" version was the following:
- any functionality should get the minimum required input to do its job. Any redundant information requires extra checks (i.e. what happens if `reviewId` does not actually belong to the `productId`?)
- the endpoints are only used by our own SPA and thus only queried by the SPA and by us via the SwaggerDocs
From a REST perspective, I agreed and changed them, since the ids are integer values and we do not risk having very long URLs.
I am wondering if there is a guideline related to choosing hierarchical API paths over flattened ones based on various criteria such as the way the API is consumed and possibly other criteria.