4 ms·

I wish I could upvote this 100 times. REST, in its most strict form, feels like it was designed for humans to directly interact with. But this is exceptionall

I wish I could upvote this 100 times. REST, in its most strict form, feels like it was designed for humans to directly interact with. But this is exceptionally rare. Access will nearly always be done programmatically, at which point a lot of the cruft of REST is unnecessary.

masklinn 4y ago
> REST, in its most strict form, feels like it was designed for humans to directly interact with. It was literally extracted from the browser’s interaction model so… kinda?
- ninkendo 4y ago
  But browsers already have HTML for this. Links are just <a> tags. POST endpoints are exposed with <form>, etc. Webpages. Why do we need a separate concept for this thing called REST if it just reduces to hypermedia in the end?
  - jgwil2 4y ago
    It seems like the article is basically calling REST an architecture or set of conventions that well-designed websites should adhere to, leaving APIs in the literal sense of the term basically out of it entirely. I mean, you could write code to parse any structured data, but if it can change anytime (because it's self-documenting?) then I'm not sure why you would bother.
    - jackling 4y ago
      I don't think that's what the article was saying. It was mainly pointing out the way people incorrectly use the term REST. I don't think the author was saying that well-designed websites should adhere to it, but rather sites that say they're REST but have APIs that are not RESTful. An HTML response is able to be parsed and interpreted by the browser, and doesn't need any special client code to interpret its meaning. It understands what's a link, and the actions it can perform on it just using the response itself. I'd argue that it's still an API, since it's still parsed, interfaced with by the system. The major difference is that the interface is uniform.
      - jgwil2 4y ago
        > I'd argue that it's still an API, since it's still parsed, interfaced with by the system. Yes, HTML is an API that browsers can interface with. But that interface is on an entirely different level of abstraction from the web application itself. When a web developer writes HTML to be sent to a client in response to some request, they are not making any changes to HTML itself, as a language, and so they are not working on that particular API at all. Rather, they are using that API to develop their own application whose purpose is entirely different from the purpose of HTML. The value they add is not related to solving the problem of exchanging and displaying hypertext documents.
  - masklinn 4y ago
    > Why do we need a separate concept for this thing called REST if it just reduces to hypermedia in the end? Because REST is the formalisation of the interaction model. It was defined in a dissertation written about it. The very first section of the chapter is called “deriving REST”. > But browsers already have HTML for this. Links are just <a> tags. POST endpoints are exposed with <form>, etc. Webpages. HTML is not an interaction model, it’s a content-type (and one which assumes and requires human mediation). REST was about formalising the underlying interaction model for machine contexts.
- recursivedoubts 4y ago
- chriswarbo 4y ago
  Browsers are merely one sort of "user agent"; it was envisaged that all sorts of agents, mostly automated, would be crawling the Web, e.g. fetching news, finding the cheapest price for some widget, etc. Unfortunately, only browsers and search indexers seem to have caught on (and many sites are actively hostile to anything else)

masklinn 4y ago

> REST, in its most strict form, feels like it was designed for humans to directly interact with. It was literally extracted from the browser’s interaction model so… kinda?

ninkendo 4y ago
But browsers already have HTML for this. Links are just <a> tags. POST endpoints are exposed with <form>, etc. Webpages. Why do we need a separate concept for this thing called REST if it just reduces to hypermedia in the end?
- jgwil2 4y ago
  It seems like the article is basically calling REST an architecture or set of conventions that well-designed websites should adhere to, leaving APIs in the literal sense of the term basically out of it entirely. I mean, you could write code to parse any structured data, but if it can change anytime (because it's self-documenting?) then I'm not sure why you would bother.
  - jackling 4y ago
    I don't think that's what the article was saying. It was mainly pointing out the way people incorrectly use the term REST. I don't think the author was saying that well-designed websites should adhere to it, but rather sites that say they're REST but have APIs that are not RESTful. An HTML response is able to be parsed and interpreted by the browser, and doesn't need any special client code to interpret its meaning. It understands what's a link, and the actions it can perform on it just using the response itself. I'd argue that it's still an API, since it's still parsed, interfaced with by the system. The major difference is that the interface is uniform.
    - jgwil2 4y ago
      > I'd argue that it's still an API, since it's still parsed, interfaced with by the system. Yes, HTML is an API that browsers can interface with. But that interface is on an entirely different level of abstraction from the web application itself. When a web developer writes HTML to be sent to a client in response to some request, they are not making any changes to HTML itself, as a language, and so they are not working on that particular API at all. Rather, they are using that API to develop their own application whose purpose is entirely different from the purpose of HTML. The value they add is not related to solving the problem of exchanging and displaying hypertext documents.
- masklinn 4y ago
  > Why do we need a separate concept for this thing called REST if it just reduces to hypermedia in the end? Because REST is the formalisation of the interaction model. It was defined in a dissertation written about it. The very first section of the chapter is called “deriving REST”. > But browsers already have HTML for this. Links are just <a> tags. POST endpoints are exposed with <form>, etc. Webpages. HTML is not an interaction model, it’s a content-type (and one which assumes and requires human mediation). REST was about formalising the underlying interaction model for machine contexts.
recursivedoubts 4y ago
chriswarbo 4y ago
Browsers are merely one sort of "user agent"; it was envisaged that all sorts of agents, mostly automated, would be crawling the Web, e.g. fetching news, finding the cheapest price for some widget, etc. Unfortunately, only browsers and search indexers seem to have caught on (and many sites are actively hostile to anything else)