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 POST to a 'factory' URI e.g. http://example.com/call can return 201 Created with the URI of the created resource in a Location: http://example.com/call/1234567 HTTP 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 POST to http://example.com/call/1234567/status might 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