Much as I enjoyed Why PUT and DELETE, I have to question Eliotte's advice. When crafting a Web API, it's worth knowing when to use GET over POST, and understanding the value of eTag is going to reap rewards, but why would a publisher rely upon PUT and DELETE given they're often blocked by the HTTP proxy your client is unwittingly behind or unavailable from J2ME and many browsers?
If like me, you're a pragmatic coward, here's a couple of ways to avoid unnecessary astronautics:
- PUT
- requires the client to assert an acceptable and unique URI when creating a new resource. Use a
POSTto a 'factory' URI e.g.http://example.com/callcan return201 Createdwith the URI of the created resource in aLocation: http://example.com/call/1234567HTTP response header. - DELETE
- isn't always what you want, and removing resources sounds intrinsically uncool to me. Whilst you might want to hang-up a telephone call, or remove that blog entry, do you really want to remove all record of it ever existing? A
POSTtohttp://example.com/call/1234567/statusmight be a better way to terminate that telephone call, or remove an image without ditching its metadata.
You'll also avoid a lot of aggravation if you can make your POSTs idempotent.
Update: I tried to reply to this thread, but my message was lost, so resorted to writing a web page. Now that's kinda ironic. Update: Nic points to AHAH which also only uses GET and POST to work in a browser, and looks pretty cool.
Technorati Tags: REST
With respect to PUT, I agree that as far as the creation of a new resource POST is better but you should take injto account that PUT conveys the semantics of a complete update of a resource and it's idempotent by default.
Stelios
I'm a little confused about the notion of DELETE being uncool. Sometimes we really, truly want to destroy resources - not just 410 Gone, but 404 Not Found.
Say I'm using a social bookmarking site, and I bookmark an internal corporate document. I realize what I did, and I want that bookmark gone. Nevermind that the bookmark pointed at a behind-firewall server - I don't even want the information pointing to that resource's existence kept around. Say the URL itself even revealed the codename of a project. Dumb, yeah, but it should be able to be deleted, no?
The best solution I've come up with so far is a hackish ?REQWUEST_METHOD=DELETE query param on an actual POST request where the user agent can't issue PUT or DELETE, where the server-side treats it as if it had really been a DELETE or PUT.
I guess there are times you want to remove a resource - never say never - but making it business as usual is uncool. An example might be the W3C mailing archive where their policy is to not remove archived items, unless it's SPAM or extenuating circumstances like yours.