6 ms·
PUT or POST: The REST of the Story
- ramen 16y agoThe idempotency of PUT is supposedly useful with caching web proxies, but I don't know of any caching web proxies that support PUT. Are there any?
- mjw 16y agoIt's not so much about caching - it's more about knowing that you're safely able to repeat a request which timed out or failed. A way to distinguish form submissions (like a credit card purchase form) which must not be repeated after submission, from things like "upload a new version of this file" which you can safely allow to be retried if they time out or fail. This is potentially useful for a bunch of different HTTP clients and client libraries, and potentially for some proxies too. Edit: actually PUT and DELETE are useful for caches - although not because of their idempotency, but just because they communicate the fact that the resource being PUT to or DELETEd may change as a result, hence the cache key for that URL should be purged. IIRC some caching proxies do do this.
- borisk 16y agoHehe, a proxy cashing PUTs can spice up your REST experience. How exactly will the proxy know someone else haven't updated a resource between 2 requests and it's safe not to pass the 2nd request to server?
- mjw 16y agoYep - it's not safe to assume you can cache a PUT in that way. AFAIK no caches do this. What they should do though is purge their cache for that URI when they see a successful PUT has happened.
- malkia 16y agoOne reason I read HN, is to learn how to come up with good titles :)
- angelbob 16y agoQuick summary: PUT is idempotent, and should be used when you're sending the full text or properties of an item, or otherwise doing some where doing it a second time is harmless. POST is not, and should be used for requests like "increment this field" or "add a new sub-item to this parent item" where doing it twice will give a very different result than doing it once.
- keefe 16y agocouchdb then technically violates this due to revision numbers
- epochwolf 16y agoI'd say the mapping is good enough. PUT updates a current object, which can be done again. POST creates a new object which can't be repeated without producing another article. CouchDB has automatic versioning which is mostly transparent to most operations. (on a single instance)
- keefe 16y agoIt was a nitpicky comment, I guess cause I am contemplating the meaning of idempotent. Two identical PUTs on an existing doc will not change the database so I guess that's OK, but their response will be different insofar as the 2nd will fail.
- epochwolf 16y agoI don't think the failed response matters. You can replay a PUT request without altering the state on the server. (Aside from the single object you're manipulating.) Replaying a POST gets you two objects with the same data.
- keefe 16y agoI think you're right because the 2nd PUT doesn't change the value of variables on the server.
- keefe 16y agoit's worth remembering that firefox won't let you PUT an attachment from a form, it must be POST which is a real pain for dealing with couchdb sometimes
- ratsbane 16y agoNot just Firefox - all HTML 4 forms support only GET and POST (though XMLHttpRequest supports any method.) HTML 5 forms do support PUT and DELETE though not HEAD. (I think this is accurate. Corrections appreciated.)
- piotrSikora 16y agoI can't agree with last few paragraphs. "Location" header should be used for redirections. There is "Content-Location" header which should be used to identify real location of the content. So, for example, for newly created objects ("POST /objects/"), you should return content with header "Content-Location: http://website.com/objects/object_id http://website.com/objects/object_id ".
- mjw 16y agoThe RFC begs to differ :) http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html "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)."
- piotrSikora 16y agoErm... I stand corrected, you're right. I think I was confused by the description under section 14.30 (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.30 http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14...).
- mjw 16y agoNo worries. Some of those HTTP RFCs are pretty crufty - there is a cleanup project in the works apparently: http://datatracker.ietf.org/wg/httpbis/charter/ http://datatracker.ietf.org/wg/httpbis/charter/
- terra_t 16y agoI ~love~ REST! People who don't know anything about building distributed systems hop on the REST bandwagon and before you know it they've got a monstrosity that doesn't work. I come in as a $150 an hour consultant, explain really clearly that it's ~very~ hard to get business rules and transactions working right in a REST situation, re-architect the system with POX RPC and get it working. When I see blog entries about the "finer points of REST" I hear ka-ching, ka-ching, ka-ching!
- borisk 16y agoYou're obviously (by your rate and believes) a newcomer to enterprise architecture ;) Distributed transactions are an anti-pattern even with WS-Transactions. And business rules belong to the services themselves, not to the service infrastructure.
- terra_t 16y agoThat's the whole problem with REST; getting transactional semantics requires distributed transactions. In RPC you can do everything you have to do in a local transaction and package it as one RPC call. Fast and simple...
- wanderr 16y agoIf only SOAP wasn't the face of RPC to most people, you probably wouldn't get downvoted so hard. ;) SOAP is horrible but REST is worse. JSON-RPC is elegant and simple. I wish more people would use it.
- mjw 16y agoWell distributed transactions in some mission-critical enterprise setting isn't what REST is all about, not even close. If people are really making that mistake fair play to you. I would hope that the majority of us out there using REST have a sense of perspective about it though. It's about providing services as part of the open web in a loosely coupled, organic, discoverable fashion based on standardised media types. And also about implementing lightweight APIs which observe the semantics of HTTP rather than layering stuff on top of it. This kind of stuff is a great fit for a lot of APIs which face the open web, or which are used by clients without hard, business-critical constraints on reliability and transactionality. The semantics of HTTP obviously weren't designed for that stuff, although they do contain some features which go part-way towards helping, which is perhaps what sets some people on a slippery slope.