3 ms·

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

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.

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.