

Ask HN: Is RESTful purity too chatty for HTTP? - leeoniya

Hello fellow hackers, I posted this question on SO and CodingForums a few days ago and have no replies yet.<p>REST principles dictate that when a resource is created or updated (POST/PUT), the response body should contain a representation of the transaction result, along with a location header of the new resource, etc. While this is all good and well, it pretty much forces you to re-request the resource to get its current state, but HTTP requests are not free - far from it. Is there an accepted approach to deal with this?<p>It would seem appropriate to return both a location header and an XML or JSON structure in the body to avoid a wasteful second AJAX request. The body can then use an envelope/namespace similar to SOAP that would separate any transaction response message from the resource representation itself.<p>originally asked here:
http://stackoverflow.com/questions/11123571/proper-way-to-minimize-rest-re-requests-on-create-update<p>thanks!
======
lifeisstillgood
My take is that for the vast majority of applications the network excess is
more than compensated for in style, simicity and predictability I like how
REST fits my brain and yes that is a rip off of an old Python slogan

returning the resource on every POST / PUT would only be correct in a subset
of use cases anyway. If you POST a wall of text to a forum why would you want
it back?

add to that you may create more than one resource (how many do you return?)

