7 ms·

EXACTLY. Regurgitators of the HATEOAS mantra never address this. Instead you get statements like one in this article: "the HTML response "carries along" all the

EXACTLY. Regurgitators of the HATEOAS mantra never address this. Instead you get statements like one in this article: "the HTML response "carries along" all the API information necessary to continue interacting with the system directly within itself." No, it doesn't. It's a list of URLs, which doesn't even indicate what operations they accept. The only thing REST supports, according to this philosophy, is a user manually traipsing through the "API" by clicking on stuff. Thanks for summing it up so succinctly; I thought maybe I was missing something.

recursivedoubts 4y ago
I'm the author, and I agree with you: a list of URLs jammed in a JSON response isn't much of a useful hypermedia affordance and, even if it was, what would some code do with it besides passing it on to a human to deal with? Old web 1.0 applications, however, let you do a lot more than traipse through an API by clicking on stuff: you can send emails, update documents and on an on, all through links and forms. The HTML, in this system, does "carry along" all the API information necessary for the client (the browser) to interact with the resources it is representing. It relies on the human user to select exactly which actions to take, which is why I say "HATEOAS is for Humans", and wrote an article on exactly that.
- NonNefarious 4y ago
  Actually, in those cases the client is a person; the browser is only the transport mechanism. But indeed we agree on the "for humans" problem. I'm inclined to accept widely-repeated guidelines on technology that I'm just learning, but this is another instance where the fallacy became obvious when it was time to implement something. Kinda like any attempt to use a lot of inheritance in OOP, which is now recognized as silly. I assume that a lot of problems are "solved," but continue to be surprised that they aren't. I defined an API using OpenAPI and am now trying to generate code for it and do some prototyping, but the whole ecosystem is a mess and the standard itself is only now shaking off some truly dumb gaffes.
  - recursivedoubts 4y ago
    Would you say that, in this paper, when Fielding says "client", he means "a person"? https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arc... Or would the browser be the client?
    - NonNefarious 4y ago
      After hastily searching for "client" and reading how it was used in several places, I would NOT say that he means a person. But I also don't think he's talking about APIs, which is what the semantic debate seems to be about in this thread. I'm not trying to undermine your point; just to clarify that I was still talking about UI vs. API.
      - recursivedoubts 4y ago
        I agree: a lot of folks don't think a hypermedia response is an API response, which maybe deserves its own essay. A hypermedia response is an API response for a hypermedia client, and additional possible API calls to the server are then discovered within that hypermedia response via hypermedia controls (e.g. links and forms) At least, that's my position, but I understand that many people would not call this an API (maybe just a RESTful system?) The language here is pretty darned academic, and Fielding didn't apologize for that: https://roy.gbiv.com/untangled/2008/specialization https://roy.gbiv.com/untangled/2008/specialization Unfortunately I think that unwillingness to come down a few pegs in abstraction ended up costing a lot in terms of confusion.
        NonNefarious 4y ago
        Indeed. Anyway, nice essay and thanks for the thoughtful responses.
bmn__ 4y ago
> It's a list of URLs, which doesn't even indicate what operations they accept. HTTP does not require a particular media type's representation to indicate the allowed methods. What made you think this should be the case? All popular media types I know either contain a partial indication (e.g. forms in HTML), and otherwise a fallback to GET/HEAD as default is implied or specified. If a client is unsure, there's always the OPTIONS method and the Allow header.
- NonNefarious 4y ago
  I never said HTTP required that. The point of this discussion is that a remote COMPUTER can't derive the means of using a URL simply because it's listed. What query parameters does it support for a GET operation, for example. This is about APIs, not bog-standard HTTP.
  - bmn__ 4y ago
    Oh, I see. The response carries along all the information necessary to continue interacting with the system directly within itself. For example, in HTML there are forms for the purpose you just mentioned, I'll give you two examples: <form method="get" action="search"> <input name="q" type="text"> <form method="get" action="filter"> <select name="items_per_page"> <option>10</option> <option>20</option> <option>50</option> </select> The server instructs what query parameters are supported via the media type and its applicable semantics that are hopefully well defined, which is the case for HTML. Since the client (here: "remote COMPUTER", respectively its user agent) understands the media type, it can successfully uphold its half of the contract and generate the correct resource identifiers and accompanying HTTP requests that are delectable to the server. The same idea applies to other media types.

recursivedoubts 4y ago

I'm the author, and I agree with you: a list of URLs jammed in a JSON response isn't much of a useful hypermedia affordance and, even if it was, what would some code do with it besides passing it on to a human to deal with? Old web 1.0 applications, however, let you do a lot more than traipse through an API by clicking on stuff: you can send emails, update documents and on an on, all through links and forms. The HTML, in this system, does "carry along" all the API information necessary for the client (the browser) to interact with the resources it is representing. It relies on the human user to select exactly which actions to take, which is why I say "HATEOAS is for Humans", and wrote an article on exactly that.

NonNefarious 4y ago
Actually, in those cases the client is a person; the browser is only the transport mechanism. But indeed we agree on the "for humans" problem. I'm inclined to accept widely-repeated guidelines on technology that I'm just learning, but this is another instance where the fallacy became obvious when it was time to implement something. Kinda like any attempt to use a lot of inheritance in OOP, which is now recognized as silly. I assume that a lot of problems are "solved," but continue to be surprised that they aren't. I defined an API using OpenAPI and am now trying to generate code for it and do some prototyping, but the whole ecosystem is a mess and the standard itself is only now shaking off some truly dumb gaffes.
- recursivedoubts 4y ago
  Would you say that, in this paper, when Fielding says "client", he means "a person"? https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arc... Or would the browser be the client?
  - NonNefarious 4y ago
    After hastily searching for "client" and reading how it was used in several places, I would NOT say that he means a person. But I also don't think he's talking about APIs, which is what the semantic debate seems to be about in this thread. I'm not trying to undermine your point; just to clarify that I was still talking about UI vs. API.
    - recursivedoubts 4y ago
      I agree: a lot of folks don't think a hypermedia response is an API response, which maybe deserves its own essay. A hypermedia response is an API response for a hypermedia client, and additional possible API calls to the server are then discovered within that hypermedia response via hypermedia controls (e.g. links and forms) At least, that's my position, but I understand that many people would not call this an API (maybe just a RESTful system?) The language here is pretty darned academic, and Fielding didn't apologize for that: https://roy.gbiv.com/untangled/2008/specialization https://roy.gbiv.com/untangled/2008/specialization Unfortunately I think that unwillingness to come down a few pegs in abstraction ended up costing a lot in terms of confusion.
      - NonNefarious 4y ago
        Indeed. Anyway, nice essay and thanks for the thoughtful responses.

bmn__ 4y ago

> It's a list of URLs, which doesn't even indicate what operations they accept. HTTP does not require a particular media type's representation to indicate the allowed methods. What made you think this should be the case? All popular media types I know either contain a partial indication (e.g. forms in HTML), and otherwise a fallback to GET/HEAD as default is implied or specified. If a client is unsure, there's always the OPTIONS method and the Allow header.

NonNefarious 4y ago
I never said HTTP required that. The point of this discussion is that a remote COMPUTER can't derive the means of using a URL simply because it's listed. What query parameters does it support for a GET operation, for example. This is about APIs, not bog-standard HTTP.
- bmn__ 4y ago
  Oh, I see. The response carries along all the information necessary to continue interacting with the system directly within itself. For example, in HTML there are forms for the purpose you just mentioned, I'll give you two examples: <form method="get" action="search"> <input name="q" type="text"> <form method="get" action="filter"> <select name="items_per_page"> <option>10</option> <option>20</option> <option>50</option> </select> The server instructs what query parameters are supported via the media type and its applicable semantics that are hopefully well defined, which is the case for HTML. Since the client (here: "remote COMPUTER", respectively its user agent) understands the media type, it can successfully uphold its half of the contract and generate the correct resource identifiers and accompanying HTTP requests that are delectable to the server. The same idea applies to other media types.