I spent all day yesterday looking at ways to deal with my endpoint API.
/users/:user_id/sources/:source_id/items/:item_id makes conceptual sense in the API construction, which I built first. But sources, items, and users all have their own ID space, and while it’s a straightforward has-many relationship straight down the chain, there’s no real reason why I can’t do /users/:id, /sources/:id, and /items/:id instead.
I’m starting to sense that there’s a general feeling that nested URLs like that are an antipattern. If nothing else, they make item lookup a lot more complicated: if I want to look up an item, I need to know its owning source and user to construct the URL, but that’s not really necessary, since the item’s ID should uniquely identify it anyway.
The requests are pretty much identical except for looking up the list of sources tied to a user on an index route to the API (/users/2/sources would list user 2’s sources, but now it’s /sources?user_id=2). That request is actually wrong anyway, because /user/2 should have a sources attribute anyway, populated with source_id values that it owns, so my “get all the sources on a user” request goes to /users, and happens automagically when I instantiate and inflate a user. Happily this is all early prototyping work (so I don’t have to support a legacy api URL structure) and I’m writing both ends of the system, so I can change my rails router to have the flat structure instead of nesting.
This isn’t so much of a question as it is an Aha! moment that I wanted to float into the community. Does this make sense? Maybe if it does, the next poor dev that is looking to break into ember-data doesn’t lose a day coming to his/her senses.