[ville]

Many parts of the HAPI spec seem to be in outright conflict with the established best practices and standards. E.g.

> A HAPI must support the HTTP GET verb on all operations.[1]

Contrast this with HTTP/1.1 RFC 2616:

> In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe".[2]

[1]: https://github.com/jheising/HAPI#general-rules

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

[jheising]

Correct. Damned be the HTTP specs and REST because they are such a pain in the ass :) I built HAPI precisely because the current standards only work in a world where everyone knows how and enjoys using curl. I think you should be able to paste a URL for an API anywhere and it should just work.

For example: Here let me show you how to delete that resource using our API... Oh wait, damn. I can't show you because I have no way of sharing a link with you because it requires the DELETE verb. Just go read this documentation and get back to me when you're done. ;)

[sunir]

And I can put that delete URI in an <img src=""> and have your browser or iPhone email automatically destroy your document before you can stop it.

[jheising]

Yes and if I were a hacker, I could do the same thing with curl. Either way the only person who's likely to do it is someone who is technically savvy.

[bluefinity]

You can do the same thing with POST by submitting a form with JS. The correct way to protect against this sort of thing is to use a CSRF token.

[oneeyedpigeon]

Submitting a form with JS is a whole other level of complexity than just having a link out there in the wild that performs write operations. And using a CSRF defeats that stated intent.