3 ms·

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

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.

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.