3 ms·

Great sunday reading. However, in the section "But how do you deal with relations?" the author presents nested resources as a best practice. I don't feel this

Great sunday reading. However, in the section "But how do you deal with relations?" the author presents nested resources as a best practice. I don't feel this is the best course of action. Instead of nesting message resources in, say, `/tickets/12/messages/5` shouldn't a better approach be to store them in `/messages/5` and keep `/tickets/12/messages` as a collection of IDs or summary resources? I mean, messages are a separate entity which might even be moved to a dedicated microservice. Why is it a good practice to nest them within an API?

arethuza 7y ago
"might even be moved to a dedicated microservice" Allowing for scenarios like that would actually be an argument for HATEOS (where, at least in theory, URLs are treated as opaque). NB I have tried designing using HATEOS and I'm not a huge fan - but it would help in this case.
LoSboccacc 7y ago
there's a trade-off involved in latency size and server hits shipping name and description of some resources often read together allows to minimize cost and optimize performances, up to a point ultimately the client knows what the UX needs and it's in the optimal position to ask for the minimal resources needed, hence graphql et al. but that leaves the rest API designer in a rut, where to make the call for nesting and where for searching related? if I had to draw the line, if the related entity has a non null foreign key (or the nearest applicative equivalent) toward the parent it's a prime candidate for nesting
- rumanator 7y ago
  > there's a trade-off involved in latency size and server hits I might have not conveyed the point adequately, but my point was orthogonal to networking or HTTP calls. I was referring to how resources were being needlessly nested, thus leaking direct dependencies wrt other resources. More specifically, although tickets might refer to messages, I didn't understood why nesting messages within a ticket passed off as a best practice. I mean, if ticket already provide a collection resource of message resource IDs, why is the path to message resources being defined specifically with regards to specific tickets?
  - bsaul 7y ago
    I think there’s some confusion on what the original problem is: how do you get the ticket, together with its messages, in the minimum number of api calls ? That’s why parent post mentions latency and graphql. The other problem : « having already queried the ticket, how do i get its messages », does indeed allow for various answers : tickets/Id/messages , or /messages?ticketid=xx or even /messages?ids=a,b,c,d are valid, depending on how orthogonal tickets and messages are, and don’t depend on latency, indeed.

arethuza 7y ago

"might even be moved to a dedicated microservice" Allowing for scenarios like that would actually be an argument for HATEOS (where, at least in theory, URLs are treated as opaque). NB I have tried designing using HATEOS and I'm not a huge fan - but it would help in this case.

LoSboccacc 7y ago

there's a trade-off involved in latency size and server hits shipping name and description of some resources often read together allows to minimize cost and optimize performances, up to a point ultimately the client knows what the UX needs and it's in the optimal position to ask for the minimal resources needed, hence graphql et al. but that leaves the rest API designer in a rut, where to make the call for nesting and where for searching related? if I had to draw the line, if the related entity has a non null foreign key (or the nearest applicative equivalent) toward the parent it's a prime candidate for nesting

rumanator 7y ago
> there's a trade-off involved in latency size and server hits I might have not conveyed the point adequately, but my point was orthogonal to networking or HTTP calls. I was referring to how resources were being needlessly nested, thus leaking direct dependencies wrt other resources. More specifically, although tickets might refer to messages, I didn't understood why nesting messages within a ticket passed off as a best practice. I mean, if ticket already provide a collection resource of message resource IDs, why is the path to message resources being defined specifically with regards to specific tickets?
- bsaul 7y ago
  I think there’s some confusion on what the original problem is: how do you get the ticket, together with its messages, in the minimum number of api calls ? That’s why parent post mentions latency and graphql. The other problem : « having already queried the ticket, how do i get its messages », does indeed allow for various answers : tickets/Id/messages , or /messages?ticketid=xx or even /messages?ids=a,b,c,d are valid, depending on how orthogonal tickets and messages are, and don’t depend on latency, indeed.