| > For example, what if a single PUT request creates multiple sub-objects? If a PUT, POST, or PATCH does that, then it does that. So what? > How does my server reply with multiple location headers? It doesn't respond with multiple location headers. With PUT or POST, with an 201 Created status response with the Location: header containing the URI of the parent object (the resource directly created by the PUT/POST), and an entity body, in some appropriate format, containing the URIs of all the created objects. (If there is a representation of the main resource which would do this that is acceptable to the client, this would seem to be an ideal way of communicating that.) With PATCH, much the same, but with 200 OK. > Do i have to first re-get the created object's child locations and re-request each individually? There's no reason for a REST API to require that. > How about just sending the full object state back as the response to my PUT request? I see no reason why sending a full resource representation in a 201 status response, provided that the client has indicated that they are willing to accept the relevant media type, is problematic, especially if it does what the HTTP/1.1 spec says the 201 response entity should do. (The one thing that common resource representations might not do that they should is provide their own location and the direct locations of any embedded subentities that are separate addressable, but there is no reason why a resource representation couldn't do that, and I'd argue that in REST it would be desirable that resource representations do do that.) > Well, according to REST, the body of the response just needs to be a description of the error or success status. As, stated, that's accurate, but you seem to be acting as if that was "needs to be just" rather than "just needs to be" (e.g., misunderstanding it as a maximum allowed content, rather than a minimum required content.) > Basically, REST sucks for reducing round trips if you're going to follow it pedantically. Except that none of the problems you've pointed to in that regard have anything to do with REST. |
You could actually go a step further - if you're using "Hypertext as the engine of application state" (HATEOAS), URIs for the locations of direct subentities need to be there, if the client is expected to be able to make those state transitions, for the API to be "fully RESTful". (Though, I'd personally agree with the article that features like discoverability and content negotiation are secondary to those you get from idempotence/properly using HTTP methods, and feel they should be considered bonus features, rather than strict requirements)