[je42]

Thinking about this:

By merging children into the parent resource, he traded a reduction of requests with the loss of separation of concerns.

How about adding a layer instead whose only concern is the reduction of the number of requests for the client. It would collect and merge the info from parent and children resources and return it in merged form to the client ?

[pbh101]

Netflix has apparently called this idea an 'orchestration layer':

http://thenextweb.com/dd/2013/12/17/future-api-design-orches...

[T-R]

I really do wish HTTP had a mechanism for responding to a single request with multiple combined response bodies as if requests were made for each individually (from the perspective of, e.g., a caching proxy) - the loss of separation of concerns from merging children into the parent isn't just a usability issue, it also means you lose your cache granularity - the cache for the parent object is now stale whenever a child is modified, and a request for a child after getting the parent won't hit the cache at the request level.

There's keep-alive, but that still means that if you want to get a parent and its children, you have to wait for the parent request round-trip.

To add - this is a major issue we've been working through at Slant.co - we've combined child objects into the requests for the parent objects (sometimes even two levels down), but it's significantly complicated caching efforts - we're in the process of building some namespacing into our server-side request cache, so we can transparently make cached Question and Option pages stale whenever, e.g., the title of a Pro/Con gets changed. If HTTP allowed multiple responses, we could treat everything transparently server-side as individual requests, and get much higher hit-rates for proxy and client-side caches.

[dragonwriter]

> I really do wish HTTP had a mechanism for responding to a single request with multiple combined response bodies as if requests were made for each individually

That seems to be a pretty significant feature of SPDY and the in-progress HTTP/2.0 work.

[T-R]

I wasn't aware of that, that's good to hear. I'm under the impression, though, that since SPDY encrypts everything, that you can't get caching at intermediate nodes unless you explicitly MITM yourself, which would reduce the utility of that feature. Then again, I'm not sure how much caching happens outside of places where you'd MITM yourself now anyway, so I guess in practice, that might not be a huge step back.

[dragonwriter]

> I wasn't aware of that, that's good to hear. I'm under the impression, though, that since SPDY encrypts everything, that you can't get caching at intermediate nodes unless you explicitly MITM yourself, which would reduce the utility of that feature.

Last I heard, it was quite a matter of debate in the IETF workgroup on HTTP2 the extent to which SPDY's "TLS is mandatory" approach would be adopted for HTTP/2.0 (IIRC, Microsoft at one point staked out a "we will enable HTTP/2.0 without TLS in our browser so the standard better allow it" position, and numerous parties making strong arguments that there were definite use cases -- especially internal networks -- where users would want the other advantages of HTTP/2.0 and where TLS would be a burden rather than a benefit.)

And if you are worried about caching internal to your own organization, you could, in the worst case, use a (TLS-required) HTTP/2.0 user facing server with HTTP/1.1 (non-TLS) internal servers, eliminating the need to MITM your own TLS traffic. Obviously, that doesn't help external cacheability, but you probably aren't going to usually want to send external content insecurely from an app.

[kalmar]

For those interested in this issue, check out JSON API's compound documents [0], and how to specify inclusion [1].

[0] http://jsonapi.org/format/#document-structure-compound-docum...

[1] http://jsonapi.org/format/#fetching-includes

[curun1r]

jsonapi looks interesting, but it's really too bad that they require HTTP. If they would change it to be more transport agnostic, it would work really well with websockets.

[lumpypua]

That would probably actually work pretty well. I've run into a similar problem a number of times and I may try this.

"All problems in computer science can be solved by another level of indirection" - David Wheeler

"...except for the problem of too many layers of indirection." - Kevlin Henney

[21echoes]

that's what we've done with our API: we have a meta-resource /multi that takes in an ordered array of Request objects, each with a URI, (HTTP)Method, and Parameters. The /multi service then splits these Requests out, sends them off to the "real" server in order (GETs, of course, being parallelizable when next to each other in the provided order), and then composes the responses back into one array of Response objects which gets passed back to the client.

It's honestly amazing to work with, as we can be very strict about our separation of concerns on the backend, while letting the frontend combine bits and pieces as makes sense for a given client interface.

[ldng]

How about using "multipart/related" ? Would make sense to me. Although I've never seen that so I guess I must be missing something.

[dreamfactory2]

An orchestration layer is found in most enterprise architectures