6 ms·
I'm not saying it is a nice API, or that it is in any way a REST API. Just that unless I am missing something, it is HTTP compliant.
by SomeOtherGuy2 15y ago
I'm not saying it is a nice API, or that it is in any way a REST API. Just that unless I am missing something, it is HTTP compliant.
- alexchamberlain 15y agoIt isn't compliant, it doesn't use the verbs properly.
- SomeOtherGuy2 15y agoWould you care to point out where in the HTTP RFCs it requires the use of certain methods for certain operations? The reality is, you can do whatever you like as far as HTTP is concerned. In fact, only GET and HEAD are required to be implemented, all the other methods are optional. HTTP does not have "verbs". That is REST. Just because they aren't using a REST API, doesn't mean they are not HTTP compliant.
- alexchamberlain 15y agoRFC 2616 http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
- SomeOtherGuy2 15y agoNow read it. Notice how it is all "SHOULD" and "SHOULD NOT". You can do whatever you want and still be HTTP compliant. Using practices that are not recommended is not the same as being non-compliant.
- spacemanaki 15y agoI'm not sure that it actually violates the letter of the law of the spec, but I think it definitely violates the spirit, based on this section: http://tools.ietf.org/html/rfc2616#page-51 http://tools.ietf.org/html/rfc2616#page-51. I thought that GET (along with a few other methods) were supposed to be "safe" and not result in any action on the server except possibly logging and stuff like that? Is this required to be HTTP compliant or is this more of a recommendation?
- SomeOtherGuy2 15y agoUnfortunately, very little is required to be HTTP compliant. It is almost all SHOULDs and SHOULD NOTs, and is full of vagueness. Here's a quick discussion of how bad the HTTP spec is for being strict and easy to implement: http://www.and.org/texts/server-http http://www.and.org/texts/server-http