6 ms·
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 ar
by joshfraser 13y ago
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?
- wereHamster 13y agoYou can't PUT or DELETE from a html <form>.
- texuf 13y agoyou also can't PUT from an embedded flash app
- joshfraser 13y agoI knew there was a simple explanation that I was forgetting.
- est 13y agobecause some stupid waf only allow POST/GET methods on port 80.
- vaidik 13y agoAlthough 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.
- deleted 13y ago[deleted]
- deleted 13y ago[deleted]
- deleted 13y ago[deleted]
- vaidik 13y agoAlthough 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.
- aaronem 13y agoSure 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 http://stackoverflow.com/a/166501/1713079
- eulerphi 13y agoImagine 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.
- aaronem 13y agoThere 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 http://www.w3.org/Protocols/rfc2616/rfc2616.html
- sandGorgon 13y agoisnt 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 http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html