Hacker News Reader

Comment by joshfraser | Hacker News Reader

Is there a good reason why so many API's avoid using PUT and DELETE? Take the Twitter API for example, they use POST /lists/destroy instead of DELETE. They are smart guys and clearly know how to design a RESTful API. What's their rationale?

View on HN

You can't PUT or DELETE from a html <form>.

I knew there was a simple explanation that I was forgetting.

because some stupid waf only allow POST/GET methods on port 80.

Although this is a possible explanation, do you consume APIs using HTML forms? Probably not. And if you desperately have to consume APIs in the browser, you'd end up writing some JavaScript.

you also can't PUT from an embedded flash app

Sure you can, although you need to do it via Ajax.

The W3C FORM element is specified with only 'get' and 'post' as permissible values for 'method', which I can only regard as a screwup on W3C's part, but I know of no similar restriction on the methods available to an XMLHttpRequest object; indeed at least one extremely well-regarded Stack Overflow answer [1] confirms that PUT and DELETE work as expected as of five years ago.

[1] http://stackoverflow.com/a/166501/1713079

isnt there a caching and idempotency implication ? from what I had learned long back - GET, PUT, DELETE are supposed to be idempotent [1]

POST is not - so possibly it's considered safer to use among muggles.

I also think PUT and DELETE are not cacheable, while POST is (given the right set of headers).

caveat: I might be completely wrong about my interpretation.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

Imagine trying to fit a vault in a cubbyhole meant for shoes. That's what RESTful APIs end up fighting with. I would gander that because DELETE refers to permanent deletion, whereas destroy is reversible, they chose to use the less confusing verb.

The real problem with trying to conform to REST is that there's no rigorous definition, and this leads to the same verb being used for slightly different purposes among APIs.

There is a rigorous definition of REST; it's called RFC 2616. [1] That probably most people who implement it don't pay as much attention to it as they should doesn't make it any less existent.

[1] http://www.w3.org/Protocols/rfc2616/rfc2616.html

Reply on news.ycombinator.com