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
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:
- requires the client to assert an acceptable and unique URI when creating a new resource. Use a
POSTto a 'factory' URI e.g.
201 Createdwith the URI of the created resource in a
Location: http://example.com/call/1234567HTTP response header.
- 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
http://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
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
POST to work in a browser, and looks pretty cool.
Technorati Tags: REST