4 ms·

Yes. You used it to enter this comment. I am using it to enter this reply. The magical client that can make use of an auto-discoverable API is called a "web

Yes. You used it to enter this comment. I am using it to enter this reply. The magical client that can make use of an auto-discoverable API is called a "web browser", which you are using right this moment, as we speak.

physicles 1y ago
This is true, but isn’t this quite far away from the normal understanding of API, which is an interface consumed by a program? Isn’t this the P in Application Programming Interface? If it’s a human at the helm, it’s called a User Interface.
- recursivedoubts 1y ago
  I agree that's a common understanding of things, but I don't think that it's 100% accurate. I think that a web browser is a client program, consuming a RESTful application programming interface in the manner that RESTful APIs are designed to be consumed, and presenting the result to a human to choose actions. I think if you restrict the notion of client to "automated programs that do not have a human driving them" then REST becomes much less useful: https://htmx.org/essays/hypermedia-clients/ https://htmx.org/essays/hypermedia-clients/ https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.html https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.h... AI may change this at some point.
  - nlawalker 1y ago
    If you allow the notion of client to include "web browser driven by humans", then what is it about Fielding's dissertation that is considered so important and original in the first place? Sure it's formal and creates some new and precise terminology, but the concept of browsing was already well established when he wrote it.
    - recursivedoubts 1y ago
      It formalized the network architecture of distributed hypermedia systems and described interesting characteristics and tradeoffs of that approach. Whether or not it did a GOOD job of that for the layman I will leave to you, only noting the confusion around the topic found, ironically, across the internet.
  - LegionMammal978 1y ago
    At that level, it would be infinitely clearer to say, "There is no such thing as a RESTful API, since the purpose of REST is to connect a system to a human user. There is only such a thing as a RESTful UI based on an underlying protocol (HTML/HTTP). But the implementation of this protocol (the web browser) is secondary to the actual purpose of the system, which is always a UI."
    - recursivedoubts 1y ago
      There is such a thing as a RESTful API, and that API must use hypertext, as is clearly laid out in Fielding's dissertation. I don't know what a RESTful UI is, but I do know what a hypertext is, how a server can return a hypertext, how a client can receive that hypertext and present it to a user to select actions from. Whether or not the API is being consumed by a script client or a browser client doesn't change the RESTful-ness of it, although it does change how useful the aspects of REST (in particular, the uniform interface) will be to that client.
      - LegionMammal978 1y ago
        > and that API must use hypertext I'd say that my web browser is not using hypertext. It is merely transforming it so that I can use the resulting hypermedia, and thereby interface with the remote host. That is, my browser isn't the one that decides how to interface with the remote host; I am. The browser implements the hypertext protocol and presents me a user interface to the remote host. Fielding might have a peculiar idea of what an "API" is, so that a "human + browser" is a programmatic application, but if that's what he says, then I think his ideas are just dumb and I shouldn't bother listening to him. > Whether or not the API is being consumed by a script client or a browser client doesn't change the RESTful-ness of it There's no way for a "script client" to use hypertext without implementing a fixed protocol on top of it, which is allegedly not-RESTful. Unless you count a search engine crawler as such a client, I guess, but that's secondary to the purpose of hypertext.
        recursivedoubts 1y ago
didntcheck 1y ago
The web browser is just following direct commands. The auto discovery and logic is implemented by my human brain
- recursivedoubts 1y ago
  Yes. https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.html https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.h...
ehutch79 1y ago
So, given a hateos api, and stock firefox (or chrome, or safari, or whatever), it will generate client views with crud functionality? Let alone ux affordances, branding, etc.
- recursivedoubts 1y ago
  Yes. You used such an api to post your reply. And I am using it as well, via the affordances presented by the mobile safari hypermedia client program. Quite an amazing system!
  - ehutch79 1y ago
    No. I was served HTML. not a json respoise that the browser discovered how to display.
    - dvtkrlbs 1y ago
      html is the hateoas response
    - recursivedoubts 1y ago
      Yes. Exactly.
    - antonvs 1y ago
      The connection between the "H" in HTML and the "H" in HATEOAS might help you connect some dots.
dwaltrip 1y ago
Wait what? So everything is already HATEOAS? I thought the “problem” was that no one was building proper restful / HATEOAS APIs. It can’t go both ways.
- recursivedoubts 1y ago
  The web, in traditional HTML-based responses, uses HATEOAS, almost by definition. JSON APIs rarely do, and when they do it's largely pointless. https://htmx.org/essays/how-did-rest-come-to-mean-the-opposite-of-rest/ https://htmx.org/essays/how-did-rest-come-to-mean-the-opposi... https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.html https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.h...
tshaddox 1y ago
I also use Google Maps, YouTube, Spotify, and Figma in the same web browser. But surely most of the functionality of those would not be considered HATEOAS.
- recursivedoubts 1y ago
  Yes, very strongly agree. Browsers, through the code-on-demand "optional" constraint on REST, have become so powerful that people have started to build RPC-style applications in them. Ironic that Fielding's dissertation contained the seed of REST's destruction!

physicles 1y ago

This is true, but isn’t this quite far away from the normal understanding of API, which is an interface consumed by a program? Isn’t this the P in Application Programming Interface? If it’s a human at the helm, it’s called a User Interface.

recursivedoubts 1y ago
I agree that's a common understanding of things, but I don't think that it's 100% accurate. I think that a web browser is a client program, consuming a RESTful application programming interface in the manner that RESTful APIs are designed to be consumed, and presenting the result to a human to choose actions. I think if you restrict the notion of client to "automated programs that do not have a human driving them" then REST becomes much less useful: https://htmx.org/essays/hypermedia-clients/ https://htmx.org/essays/hypermedia-clients/ https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.html https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.h... AI may change this at some point.
- nlawalker 1y ago
  If you allow the notion of client to include "web browser driven by humans", then what is it about Fielding's dissertation that is considered so important and original in the first place? Sure it's formal and creates some new and precise terminology, but the concept of browsing was already well established when he wrote it.
  - recursivedoubts 1y ago
    It formalized the network architecture of distributed hypermedia systems and described interesting characteristics and tradeoffs of that approach. Whether or not it did a GOOD job of that for the layman I will leave to you, only noting the confusion around the topic found, ironically, across the internet.
- LegionMammal978 1y ago
  At that level, it would be infinitely clearer to say, "There is no such thing as a RESTful API, since the purpose of REST is to connect a system to a human user. There is only such a thing as a RESTful UI based on an underlying protocol (HTML/HTTP). But the implementation of this protocol (the web browser) is secondary to the actual purpose of the system, which is always a UI."
  - recursivedoubts 1y ago
    There is such a thing as a RESTful API, and that API must use hypertext, as is clearly laid out in Fielding's dissertation. I don't know what a RESTful UI is, but I do know what a hypertext is, how a server can return a hypertext, how a client can receive that hypertext and present it to a user to select actions from. Whether or not the API is being consumed by a script client or a browser client doesn't change the RESTful-ness of it, although it does change how useful the aspects of REST (in particular, the uniform interface) will be to that client.
    - LegionMammal978 1y ago
      > and that API must use hypertext I'd say that my web browser is not using hypertext. It is merely transforming it so that I can use the resulting hypermedia, and thereby interface with the remote host. That is, my browser isn't the one that decides how to interface with the remote host; I am. The browser implements the hypertext protocol and presents me a user interface to the remote host. Fielding might have a peculiar idea of what an "API" is, so that a "human + browser" is a programmatic application, but if that's what he says, then I think his ideas are just dumb and I shouldn't bother listening to him. > Whether or not the API is being consumed by a script client or a browser client doesn't change the RESTful-ness of it There's no way for a "script client" to use hypertext without implementing a fixed protocol on top of it, which is allegedly not-RESTful. Unless you count a search engine crawler as such a client, I guess, but that's secondary to the purpose of hypertext.
      - recursivedoubts 1y ago

didntcheck 1y ago

The web browser is just following direct commands. The auto discovery and logic is implemented by my human brain

recursivedoubts 1y ago
Yes. https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.html https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.h...

ehutch79 1y ago

So, given a hateos api, and stock firefox (or chrome, or safari, or whatever), it will generate client views with crud functionality? Let alone ux affordances, branding, etc.

recursivedoubts 1y ago
Yes. You used such an api to post your reply. And I am using it as well, via the affordances presented by the mobile safari hypermedia client program. Quite an amazing system!
- ehutch79 1y ago
  No. I was served HTML. not a json respoise that the browser discovered how to display.
  - dvtkrlbs 1y ago
    html is the hateoas response
  - recursivedoubts 1y ago
    Yes. Exactly.
  - antonvs 1y ago
    The connection between the "H" in HTML and the "H" in HATEOAS might help you connect some dots.

dwaltrip 1y ago

Wait what? So everything is already HATEOAS? I thought the “problem” was that no one was building proper restful / HATEOAS APIs. It can’t go both ways.

recursivedoubts 1y ago
The web, in traditional HTML-based responses, uses HATEOAS, almost by definition. JSON APIs rarely do, and when they do it's largely pointless. https://htmx.org/essays/how-did-rest-come-to-mean-the-opposite-of-rest/ https://htmx.org/essays/how-did-rest-come-to-mean-the-opposi... https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.html https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.h...

tshaddox 1y ago

I also use Google Maps, YouTube, Spotify, and Figma in the same web browser. But surely most of the functionality of those would not be considered HATEOAS.

recursivedoubts 1y ago
Yes, very strongly agree. Browsers, through the code-on-demand "optional" constraint on REST, have become so powerful that people have started to build RPC-style applications in them. Ironic that Fielding's dissertation contained the seed of REST's destruction!