Comment by osigurdson
3 days ago
>> /things/:id/child/:child_id
It seems that nesting isn't super common in my experience. Maybe two levels if completely composite but they tend to be fairly flat.
3 days ago
>> /things/:id/child/:child_id
It seems that nesting isn't super common in my experience. Maybe two levels if completely composite but they tend to be fairly flat.
Generally only /companies/:companyId/buildings
And then you get a list of all buildings for this company.
Every building has a url like: /buildings/:buildingId
So you constantly get back to the root.
Only exception is generally a tenant id which goes upfront for all requests for security/scoping purposes.
This seems like a really good model. It keeps things flat and easy to extend.
I see both.
E.g. GitHub /repos/:owner/:repo/pulls/comments/:comment_id
But flat is better than nested, esp if globally unique IDs are used already (and they often are).
Yes but /comments/:comment_uuid that has a parent to /pulls/:pull_uuid is harder to map the hierarchy it belongs to.
Not really if an URL link is added to the post in the comment response.
Also it is possible to embed a sub resource (or part of it).
Think a blog post.
/blogPost/:blogPostId
You can embed a blog object with the url and title so you can show the blogpost on a page with the name of the blog in one go.
If you need more details on the blog you can request /blogs/:blogId