4 ms·

I am the author and I agree with most of what you are saying here, REST and HATEOAS are for humans: https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.

I am the author and I agree with most of what you are saying here, REST and HATEOAS are for humans: https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.html https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.h... I disagree that it isn't an API, but that's a definition quibble. It is probably more profitable to talk about RESTful systems rather than RESTful APIs, since people think API == machines talking.

SilasX 4y ago
That feels like a pretty significant quibble. API stands for “application programming interface”. If you cannot write an application to programmatically interface with it, why would you call it an API? What you and the parent see REST as, should be called an HPAI: “human-poking-around interface”.
- recursivedoubts 4y ago
  REST is an application programming interface for RESTful systems, interpreted by RESTful clients (browsers). Generic Data APIs, and the clients that use them, are different and have different needs.
  - SilasX 4y ago
    >REST is an application programming interface for RESTful systems, interpreted by RESTful clients (browsers). No, the interpretation is done by the human using the browser, which is what makes it not programmable against, violating the P in the acronym.
    - recursivedoubts 4y ago
      The brower, a hypermedia client, sees the links, for example, in the API responses and renders them for the human to interact with. The browser is a hypermedia client, working against a hypermedia API. It not understanding the content of the responses beyond the hypermedia layer is by design: that's the uniform interface of REST. I mean, this is quibbling over definitions. I agree entirely with your general point that REST hasn't worked out well as a network architecture for non-hypermedia clients.
- Aeolun 4y ago
  You can see the HTML website as a API, just because it’s hard and annoying to interface with it from another application doesn’t mean that you can’t.
  - SilasX 4y ago
    Right. But the issue wasn’t whether you can interface with one via other applications, but whether you can do so while adhering to the REST principles Fielding gave, which require that you not have any context to interpret a response other than the response itself. So no out-of-band communication like documentation or your previous use or the site. At that point, you do need a human at each point, and you can’t program against it. Programmatically interacting involves precisely the things REST principles prohibit, hence this point in the discussion.
mercutio2 4y ago
You don’t mention Content-Type anywhere I could find in your post. I don’t think hypermedia is only for humans. You can totally do REST for computers. You’re just supposed to divide knowledge along Content-Type boundaries. It’s true people mostly don’t do this, but it works great when people bother to describe rich Content-Types.
- recursivedoubts 4y ago
  I mention Content-Type in that I think that discussions around it have largely been a distraction from what I consider the core innovation of REST: the uniform interface. I recognize that many of the few people who still talk about REST would disagree with me on that.
  - Aeolun 4y ago
    You cannot have the uniform interface without the content type, unless you intend to stay strictly theoretical. Most programmers have zero interest in staying theoretical, and since everyone had shit to do, and nobody felt like making a whole new content type for their applications, we ended up with only the parts that were immediately useful to people being adopted.
codethief 4y ago
> I disagree that it isn't an API, but that's a definition quibble. I don't understand: An API is an application programming interface, i.e. it is meant to be consumed by other programs. How does that go together with > REST and HATEOAS are for humans ? And how does that go together with the requirements of "no interpretation needed" and therefore "little coupling" between client and server that were mentioned in the article? Any API must be interpreted by the calling application – i.e. the caller must know what they are calling and what responses they might get. Otherwise they cannot do anything useful with it – at least not in an automatic (programmatic) fashion. I really don't understand how something can be a REST API on the one hand (clear, well-documented interface; used for programming), and on the other hand is supposed to be "for humans" and devoid of "interpretation" on the client's part. (Leaving aside that, even if this were possible, the interpretation would simply be done by the very final client of the API: The human.) All in all, I simply fail to see how ideas like "REST is for humans", HATEOAS etc. are supposed to be actionable in the real world.
- recursivedoubts 4y ago
  A concrete action I would suggest is splitting your data API out from your hypermedia API: https://htmx.org/essays/hypermedia-apis-vs-data-apis/ https://htmx.org/essays/hypermedia-apis-vs-data-apis/ Use hypermedia (and, who would have guessed I'd recommend this? something like htmx) to build your web application. Use GraphQL or whatever other nonRESTful technology fits best to build your data API.
  - Sohcahtoa82 4y ago
    Isn't this just server-side rendering, just doing sections of the page rather than the full page? Looks like it's encouraging coming almost full circle back to web 1.0 where all HTML was generated by the server.
    - recursivedoubts 4y ago
      Yes.
- 4y ago
Linosaurus 4y ago
> It is probably more profitable to talk about RESTful systems rather than RESTful APIs, since people think API == machines talking. If it's your stance that an interface designed to be interpreted by a program cannot be RESTful, then you could just shorten your rant to 'REST APIs cannot exist by definition'. It would save time. It's fair enough to be annoyed by words changing meaning I suppose. It also seems like your RESTful system definition would include any server serving up straight html without client side scripting.

SilasX 4y ago

That feels like a pretty significant quibble. API stands for “application programming interface”. If you cannot write an application to programmatically interface with it, why would you call it an API? What you and the parent see REST as, should be called an HPAI: “human-poking-around interface”.

recursivedoubts 4y ago
REST is an application programming interface for RESTful systems, interpreted by RESTful clients (browsers). Generic Data APIs, and the clients that use them, are different and have different needs.
- SilasX 4y ago
  >REST is an application programming interface for RESTful systems, interpreted by RESTful clients (browsers). No, the interpretation is done by the human using the browser, which is what makes it not programmable against, violating the P in the acronym.
  - recursivedoubts 4y ago
    The brower, a hypermedia client, sees the links, for example, in the API responses and renders them for the human to interact with. The browser is a hypermedia client, working against a hypermedia API. It not understanding the content of the responses beyond the hypermedia layer is by design: that's the uniform interface of REST. I mean, this is quibbling over definitions. I agree entirely with your general point that REST hasn't worked out well as a network architecture for non-hypermedia clients.
Aeolun 4y ago
You can see the HTML website as a API, just because it’s hard and annoying to interface with it from another application doesn’t mean that you can’t.
- SilasX 4y ago
  Right. But the issue wasn’t whether you can interface with one via other applications, but whether you can do so while adhering to the REST principles Fielding gave, which require that you not have any context to interpret a response other than the response itself. So no out-of-band communication like documentation or your previous use or the site. At that point, you do need a human at each point, and you can’t program against it. Programmatically interacting involves precisely the things REST principles prohibit, hence this point in the discussion.

mercutio2 4y ago

You don’t mention Content-Type anywhere I could find in your post. I don’t think hypermedia is only for humans. You can totally do REST for computers. You’re just supposed to divide knowledge along Content-Type boundaries. It’s true people mostly don’t do this, but it works great when people bother to describe rich Content-Types.

recursivedoubts 4y ago
I mention Content-Type in that I think that discussions around it have largely been a distraction from what I consider the core innovation of REST: the uniform interface. I recognize that many of the few people who still talk about REST would disagree with me on that.
- Aeolun 4y ago
  You cannot have the uniform interface without the content type, unless you intend to stay strictly theoretical. Most programmers have zero interest in staying theoretical, and since everyone had shit to do, and nobody felt like making a whole new content type for their applications, we ended up with only the parts that were immediately useful to people being adopted.

codethief 4y ago

> I disagree that it isn't an API, but that's a definition quibble. I don't understand: An API is an application programming interface, i.e. it is meant to be consumed by other programs. How does that go together with > REST and HATEOAS are for humans ? And how does that go together with the requirements of "no interpretation needed" and therefore "little coupling" between client and server that were mentioned in the article? Any API must be interpreted by the calling application – i.e. the caller must know what they are calling and what responses they might get. Otherwise they cannot do anything useful with it – at least not in an automatic (programmatic) fashion. I really don't understand how something can be a REST API on the one hand (clear, well-documented interface; used for programming), and on the other hand is supposed to be "for humans" and devoid of "interpretation" on the client's part. (Leaving aside that, even if this were possible, the interpretation would simply be done by the very final client of the API: The human.) All in all, I simply fail to see how ideas like "REST is for humans", HATEOAS etc. are supposed to be actionable in the real world.

recursivedoubts 4y ago
A concrete action I would suggest is splitting your data API out from your hypermedia API: https://htmx.org/essays/hypermedia-apis-vs-data-apis/ https://htmx.org/essays/hypermedia-apis-vs-data-apis/ Use hypermedia (and, who would have guessed I'd recommend this? something like htmx) to build your web application. Use GraphQL or whatever other nonRESTful technology fits best to build your data API.
- Sohcahtoa82 4y ago
  Isn't this just server-side rendering, just doing sections of the page rather than the full page? Looks like it's encouraging coming almost full circle back to web 1.0 where all HTML was generated by the server.
  - recursivedoubts 4y ago
    Yes.
4y ago

Linosaurus 4y ago

> It is probably more profitable to talk about RESTful systems rather than RESTful APIs, since people think API == machines talking. If it's your stance that an interface designed to be interpreted by a program cannot be RESTful, then you could just shorten your rant to 'REST APIs cannot exist by definition'. It would save time. It's fair enough to be annoyed by words changing meaning I suppose. It also seems like your RESTful system definition would include any server serving up straight html without client side scripting.