6 ms·

In what way is it not compliant?

alexchamberlain 15y ago
Custom headers should be prepended with "X-". Also, the top line should read POST rest/getAuthID.aspx HTTP/1.1 Correction: Use of "X-" has been depreciated in a draft resolution. Edit: As mentioned below, it isn't compliant in its use of the verbs (GET/POST etc).
- SomeOtherGuy2 15y ago
  Custom headers do not REQUIRE a prefix. So the lack of prefix does not make it non-compliant. In fact, the HTTP RFC doesn't even say they SHOULD have a prefix. And RFC822 which defines headers only says that protocol mandated headers MUST NOT be prefixed with "X-". Also, there's a draft proposal to deprecate the "X-" header prefix as it does more harm than good: http://tools.ietf.org/html/draft-ietf-appsawg-xdash-02 http://tools.ietf.org/html/draft-ietf-appsawg-xdash-02 Second, absolute URIs are perfectly valid, all HTTP/1.1 servers MUST accept them: http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.1 http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.1
nickyp 15y ago
It's not 'compliancy' as much as they're reinventing the wheel. REST was born out of a philosophy that the HTTP protocol already solved much of what you wanted to do. HTTP not only solved this, but solved this a long time ago and with 'great success' (aka The Interwebs ;-) - Authentication mechanism - Operations (CRUD) -> GET, PUT, POST, DELETE, ... - Caching -> Use HTTP caching mechanisms... - Resources -> URL's - Formats -> mime-types + use a HTTP Accept: header - ... They reinvent the wheel on many of the bullet points above: custom operations, custom format handling, custom authentication mechanisms, ... That's why this really is one of the worst implementation of an 'RESTful' API
- 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 ago
    It isn't compliant, it doesn't use the verbs properly.
    - SomeOtherGuy2 15y ago
      Would 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 ago
        RFC 2616 http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
        SomeOtherGuy2 15y ago
        Now 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 ago
        I'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?

Custom headers should be prepended with "X-". Also, the top line should read POST rest/getAuthID.aspx HTTP/1.1 Correction: Use of "X-" has been depreciated in a draft resolution. Edit: As mentioned below, it isn't compliant in its use of the verbs (GET/POST etc).

SomeOtherGuy2 15y ago
Custom headers do not REQUIRE a prefix. So the lack of prefix does not make it non-compliant. In fact, the HTTP RFC doesn't even say they SHOULD have a prefix. And RFC822 which defines headers only says that protocol mandated headers MUST NOT be prefixed with "X-". Also, there's a draft proposal to deprecate the "X-" header prefix as it does more harm than good: http://tools.ietf.org/html/draft-ietf-appsawg-xdash-02 http://tools.ietf.org/html/draft-ietf-appsawg-xdash-02 Second, absolute URIs are perfectly valid, all HTTP/1.1 servers MUST accept them: http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.1 http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.1

nickyp 15y ago

It's not 'compliancy' as much as they're reinventing the wheel. REST was born out of a philosophy that the HTTP protocol already solved much of what you wanted to do. HTTP not only solved this, but solved this a long time ago and with 'great success' (aka The Interwebs ;-) - Authentication mechanism - Operations (CRUD) -> GET, PUT, POST, DELETE, ... - Caching -> Use HTTP caching mechanisms... - Resources -> URL's - Formats -> mime-types + use a HTTP Accept: header - ... They reinvent the wheel on many of the bullet points above: custom operations, custom format handling, custom authentication mechanisms, ... That's why this really is one of the worst implementation of an 'RESTful' API

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 ago
  It isn't compliant, it doesn't use the verbs properly.
  - SomeOtherGuy2 15y ago
    Would 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 ago
      RFC 2616 http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
      - SomeOtherGuy2 15y ago
        Now 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 ago
      I'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?