3 ms·
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 op
by 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 agoI 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.