I’m in charge of designing a routing system (along with the URL structure) for a relatively small app. The app itself should provide with the functional for adding “root” level entities as well as the ability to add child (nested) entities from the context of their parents.
Considering the following sample setup:
- Root entity:
Dogs. - Child entity:
Vaccinations
I’m having the following UI routing (the BE routing is easy as it’s always flat and I can use VERBs to my advantage):
NOTE: The chances for getting more than 1 level of nesting are pretty immaterial, but if they will materialize, it might become an issue…
Root level:
- GET:
/dogs?param1=value1&... - POST:
/dogs/add - PUT:
/dogs/10/update - DELETE
/dogs/10/delete - CUSTOM
/dogs/10/custom
Nested level:
- GET:
/dogs/10/vaccinations?param1=value1&... - POST:
/dogs/10/vaccinations/add - PUT:
/dogs/10/vaccinations/25/update - DELETE:
/dogs/10/vaccinations/25/delete - CUSTOM:
/dogs/10/vaccinations/25/custom
While this works for me, I can see another approach afloat whereby instead of:
/dogs/10/vaccinations/25/add
people would use:
/dogs/10/addvaccinations/25
which results in a slightly shorter URL but incurs the processing overhead related to stepping away from resource notation – i.e addvaccinations needs to be converged to vaccinations + add.
I know REST is only a recommendations set, so I’d like to see what people think about my original approach and possibly gather any additional concerns/suggestions.
vladimir_1969_2 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.