PUT or POST: The REST of the Story

Quick 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.

The 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?

One reason I read HN, is to learn how to come up with good titles :)

I 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.<p>So, for example, for newly created objects ("POST /objects/"), you should return content with header "Content-Location: <a href="http://website.com/objects/object_id" rel="nofollow">http://website.com/objects/object_id</a> ".

it'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

I ~love~ REST!<p>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.<p>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.<p>When I see blog entries about the "finer points of REST" I hear ka-ching, ka-ching, ka-ching!