What's missing from REST

Assuming that you might need to build an object model representing resources that are exposed through REST interface. Each of the resources are exposed through designed URI. In order to build the object model (which might result in a data structure in memory on the client) you need to consume different set of URIs which in turn results in submitting collection of HTTP requests. Depending on the volume of resources and how complicated the object model is number of HTTP GETs will vary but what;s inevitable is the number of consecutive HTTP GETs which preferably should be avoided.

The first thing comes to mind is the support for HTTP pipelining. How would you send a batch of requests to your REST engine and how will you associate the responses with the object model entities?

One might provide a design strategy for REST service provider and consumer to support HTTP pipelining by perhaps grouping request in one single customized HTTP GET request and wrap responses in one HTTP response and associate them with entities using some tag mechanism, but this is down to how you design and implement REST interfaces on your own server and consumer. But what if you are consuming an already implemented REST service? The question is standardizing the concept. This is not there already and to my belief this is what could be one major flaw in existing REST engine implementations.

Something to think about.

I will add more into this post with some examples to elaborate on the concept.