4 ms·

I wholeheartedly agree with the majority of this. In my experience “REST” has been like a religion in which hardly anyone either read the founding text or bothe

I wholeheartedly agree with the majority of this. In my experience “REST” has been like a religion in which hardly anyone either read the founding text or bothered to interpret very much of it. Fielding’s thesis does not require all of what adherents have claimed it does. An API does not a priori need to adhere to any sect of “REST”, though for many use cases it will benefit. For example, a machine-to-machine API might well have verb URLs to execute something. That’s verboten, a sin but not an excommunicating taboo, in “REST”. The torch carriers can get very specific about a great many aspects, too. I find it refreshing when someone makes good use of HTTP in a way that REST would forbid. For example, if memory serves, Elasticsearch’s search API uses a GET verb, appropriate for retrieving, with a request body to provide information that would be super awkward in the URI. This API is not intended for UI usage, so why not do this? User interfaces can very much benefit from strategic adoption of application state transitions modeled via hypermedia-style links, that’s entirely different. How likely is it, however, that even if Roy wrote an article in a major publication and gave talks at conferences about what’s not really REST, the community would change its use of “RESTful”?

h0h0h0h0111 5y ago
>How likely is it, however, that even if Roy wrote an article in a major publication and gave talks at conferences about what’s not really REST, the community would change its use of “RESTful”? Ha if agile is anything to go by, people on LinkedIn will be describing their recruiting process or marketing strategy or breakfast as RESTful
- bryanrasmussen 5y ago
  our recruiting process is based on a set of idempotent responses, for example if you send in a cover letter for a full stack position we immediately respond with an email asking you to confirm that you are a rockstar ninja.
fatnoah 5y ago
>I find it refreshing when someone makes good use of HTTP in a way that REST would forbid I've written many "REST" interfaces in my time and definitely tried to make the "right" choice vs. the dogmatically correct one when it made sense. I still have a copy of API documentation I wrote "with apologies to Roy Fielding."
electroly 5y ago
> This API is not intended for UI usage, so why not do this? There are HTTP clients that are incapable of sending a request body with a GET request, because the original HTTP/1.1 RFC [1] says that a client must not send a request body in a GET request. This has changed with newer RFCs, but 2616-compliant clients still exist. If you're going to do this, you need to support POST as well, to accommodate those clients. Indeed, ElasticSearch accepts both methods. At that point perhaps you might consider whether it's worth doing just to have a conceptually clearer HTTP method. My take on TFA as it pertains to this issue would be: why bother with the strict adherence to perceived REST principles here? The search API endpoint is not a resource that you're requesting that is identified by that URL; it's an operation you're performing, so why not just treat it like the RPC that it really is? [1] https://datatracker.ietf.org/doc/html/rfc2616 https://datatracker.ietf.org/doc/html/rfc2616 [2] "A message-body MUST NOT be included in a request if the specification of the request method (section 5.1.1) does not allow sending an entity-body in requests"
- quantified 5y ago
  Conceptually clearer HTTP methods is another valid direction to consider. Of course, the farther we wander from hypermedia, the farther we wander from the HT part of HTTP. At some point we recognize that HTTP became popular because firewalls let port 80 and port 443 traffic in and we have code-level APIs to do work, we just try to make our work look like it’s hypertext.

h0h0h0h0111 5y ago

>How likely is it, however, that even if Roy wrote an article in a major publication and gave talks at conferences about what’s not really REST, the community would change its use of “RESTful”? Ha if agile is anything to go by, people on LinkedIn will be describing their recruiting process or marketing strategy or breakfast as RESTful

bryanrasmussen 5y ago
our recruiting process is based on a set of idempotent responses, for example if you send in a cover letter for a full stack position we immediately respond with an email asking you to confirm that you are a rockstar ninja.

fatnoah 5y ago

>I find it refreshing when someone makes good use of HTTP in a way that REST would forbid I've written many "REST" interfaces in my time and definitely tried to make the "right" choice vs. the dogmatically correct one when it made sense. I still have a copy of API documentation I wrote "with apologies to Roy Fielding."

electroly 5y ago

> This API is not intended for UI usage, so why not do this? There are HTTP clients that are incapable of sending a request body with a GET request, because the original HTTP/1.1 RFC [1] says that a client must not send a request body in a GET request. This has changed with newer RFCs, but 2616-compliant clients still exist. If you're going to do this, you need to support POST as well, to accommodate those clients. Indeed, ElasticSearch accepts both methods. At that point perhaps you might consider whether it's worth doing just to have a conceptually clearer HTTP method. My take on TFA as it pertains to this issue would be: why bother with the strict adherence to perceived REST principles here? The search API endpoint is not a resource that you're requesting that is identified by that URL; it's an operation you're performing, so why not just treat it like the RPC that it really is? [1] https://datatracker.ietf.org/doc/html/rfc2616 https://datatracker.ietf.org/doc/html/rfc2616 [2] "A message-body MUST NOT be included in a request if the specification of the request method (section 5.1.1) does not allow sending an entity-body in requests"

quantified 5y ago
Conceptually clearer HTTP methods is another valid direction to consider. Of course, the farther we wander from hypermedia, the farther we wander from the HT part of HTTP. At some point we recognize that HTTP became popular because firewalls let port 80 and port 443 traffic in and we have code-level APIs to do work, we just try to make our work look like it’s hypertext.