3 ms·

This chart, for POST, has it returning the new user. Strictly speaking, why would a POST return something other than status info and a URL for the created reso

This chart, for POST, has it returning the new user. Strictly speaking, why would a POST return something other than status info and a URL for the created resource (if successful)? The spec says: If a resource has been created on the origin server, the response SHOULD be 201 (Created) and contain an entity which describes the status of the request and refers to the new resource, and a Location header (see section 14.30). Is it assumed that the client will automatically follow that Location header and GET this resource? That would make some sense (perhaps most of the time) but that's different from having the POST request itself return the resource directly which is what's suggested by this chart.

wereHamster 13y ago
Saves you one roundtrip.
- jamesbritt 13y ago
  This is true, and is an argument for pragmatism over strict adherence to the spec. But if we take that route at what point do we start telling people they're doing it wrong or that they're API isn't _really_ RESTful? I'm inclined to think the answer is "never" and just encourage people to create APIs that are appropriate for the actual circumstances. There are generally practical reasons to be RESTy, but "a foolish consistency" and all that comes into play as well.
dragonwriter 13y ago
An entity representing the state of the created resource does describe the status of the request, though its a particular verbose way of doing it in most cases. It's potentially, with a large resource, a lot of wasted bits if all the client wants is status confirmation, but, in a strict request/response setup, it saves you a server roundtrip. In SPDY / HTTP/2.0 it might make sense to send a smaller request that really is just a status response while pushing the actual resource to a client willing to accept it: in cases where the followup action would be to fetch the request, you won't need an extra roundtrip (though you will get a few extra bits of bandwidth for the intermediate response.)

wereHamster 13y ago

Saves you one roundtrip.

jamesbritt 13y ago
This is true, and is an argument for pragmatism over strict adherence to the spec. But if we take that route at what point do we start telling people they're doing it wrong or that they're API isn't _really_ RESTful? I'm inclined to think the answer is "never" and just encourage people to create APIs that are appropriate for the actual circumstances. There are generally practical reasons to be RESTy, but "a foolish consistency" and all that comes into play as well.

dragonwriter 13y ago

An entity representing the state of the created resource does describe the status of the request, though its a particular verbose way of doing it in most cases. It's potentially, with a large resource, a lot of wasted bits if all the client wants is status confirmation, but, in a strict request/response setup, it saves you a server roundtrip. In SPDY / HTTP/2.0 it might make sense to send a smaller request that really is just a status response while pushing the actual resource to a client willing to accept it: in cases where the followup action would be to fetch the request, you won't need an extra roundtrip (though you will get a few extra bits of bandwidth for the intermediate response.)