Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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



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. ;)


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.


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.


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.


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: