[leeoniya]

the place where REST over HTTP fails badly IMO is batch operations and deep operations. when creating multiple entities at once, you cannot get back multiple location headers. and even if you could get back several headers, you have to re-request each of them via http to get their contents. it obligates you to be needlessly chatty.

deep ops on multiple objects complicate things even further.

i feel like once you get outside the realm of basic document storage (which is what HTTP was designed for), REST via HTTP headers completely breaks down into custom hackery for which there are no standards.

[DougWebb]

For sending and retrieving multiple entities, you can use Multipart messages. The HTTP Location header would be a url for re-retrieving the multipart message, which is a representation of the resource which is the result of your request, and each of the entities within the message would need to have their own urls embedded within their representations.

I've used this approach for exactly the situation you're describing: batch operations that return multiple entities.

[mmerickel]

Yes, totally. It is completely lacking any mechanism that allows collection-level operations. If you want to create a bunch of resources you have to abandon the supported headers and return a list of ETags in the body, removing any niceties the client would've given you for standard "REST" support. Same for the Content-Location that you mentioned.

[Roboprog]

In practice, I don't think that stops people from making REST APIs that PUT/POST lists of sub-documents that each have an embedded ID.