6 ms·

Hypermedia Clients

85 points by telotortium 4y ago

pvillano 4y ago
I seriously thought the conclusion was going to be presenting formated HTML or compact JSON* depending on ACCEPT headers or BSON or graphql
replwoacause 4y ago
I love HTMX. I think it is brilliant.
amw-zero 4y ago
The only actual benefit I've ever been able to come up with for HATEOAS / "true" REST, is that it allows servers to evolve independently from clients. As in, you can change endpoints under the hood, but as long as the names of the hypermedia controls stay the same, the client doesn't actually need to change. That is, it's just a level of indirection based on names. What I'm looking for someone to answer is, when I control both the client and server, why is this a benefit?
- ucarion 4y ago
  REST as understood by Fielding is useful when you have a highly heterogeneous, connected set of things your clients and servers operate on, like websites or a government intelligence system. These sorts of domains are pretty uncommon. It's far more than just an extra layer of indirection to keep backwards compatibility; in practice, you can't change HTTP-layer APIs regardless of your hypermedia controls. People bookmark things and write curl scripts.
  - nerdponx 4y ago
    I'm not entirely sure. Fetching attributes of related entities and pagination are really common operations, and those are natural cases where providing the client with pre-built URLs can make the client's job a lot simpler.
- dustingetz 4y ago
  tools
- webmaven 4y ago
  > What I'm looking for someone to answer is, when I control both the client and server, why is this a benefit? If you (and only you, personally) control both the client and the server (and by "control" I mean you can update/deploy them as you please, simultaneously if necessary), you can feel free to use any sort of homebrew efficient binary stateful protocol and format you like, with no consequence. However, the more parties that are involved (co-workers, separate teams, external organizations, etc.), and the less those parties are able/willing to synchronize their efforts over time, the more benefit you will see from aspects of REST and HATEOAS. Most developers aren't working in a domain and environment where the diversity of stakeholders is maximally broad for both the client(s) and server(s), so "going full HATEOAS" is often overkill, but you should still understand it, in the same way that you need to understand why data schemas ideally conform to fourth normal form, even if your production data is denormalized in practice. While some benefits from some REST practices can start accruing even in the single developer situation, simply because there can be costs to coordinating between present-you and various versions of past-you and future-you, and their respective client and server deployments, that only makes a case for partial adoption. By all means, only use the practices and patterns that make sense and solve or avoid a pain point for you in your situation rather than being dogmatic. In that sense, REST and HATEOAS shouldn't be considered in any different light than other aspects of writing software such as external dependencies, or changing the toolchain, or splitting some code into its own library or module, or publishing code as open source; sometimes it makes sense, sometimes not (especially when the costs are concrete and the benefits hypothetical).
- recursivedoubts 4y ago
  A few benefits of the hypermedia approach are: - It can be a much simpler approach to building an application. As evidence for this fact, consider Contexte's experience moving from react to htmx for their Saas application: https://htmx.org/essays/a-real-world-react-to-htmx-port/ https://htmx.org/essays/a-real-world-react-to-htmx-port/. They reduced their codebase to 1/3rd the size with no reduction in UX, dropped JS dependencies by 95%, etc. Not every project is this amenable to hypermedia, but many are. - Related to this, hypermedia is the "native" architecture of the web, and browsers have a lot of technology built into them for it. htmx is a depenedency-free 12k library because it builds on top of that model. - By adopting hypermedia as your system architecture, you push your logic back onto the server side, where you are free to use whatever programming language you prefer: clojure, python, haskell, etc. This lets you write more code in your preferred programming language and execution environment. - The server side is a trusted computing environment, so you can have complete access to a data store when writing logic there. This is in contrast with the browser, where you can't have unrestricted access to the data store due to the fact that a hostile user can open a console and start manipulating the data store. On the server side, you can just use SQL. On the client side, you can't, without putting your whole data store at risk. There are certainly tradeoffs associated with the hypermedia approach: it doesn't work well in situations when you need to respond quickly to many UI-driven events, it sacrifices representational efficiency for flexibility, etc. There isn't a silver bullet, after all. With htmx I am trying to expand the set of applications for which the hypermedia approach will work, but I have no illusions that it will work for everyone: nothing is right for everything.
  - amw-zero 4y ago
    > It can be a much simpler approach to building an application This is not related to hypermedia, this is related to server-rendering vs. client-rendering. Everyone knows that server-rendering saves on some code and JS. This is a tradeoff, for less control over the stateful aspects of the client. > Related to this, hypermedia is the "native" architecture of the web But, that was the text-based web. Hypermedia isn't necessary (or desired) for applications, which the web has moved towards supporting. > By adopting hypermedia as your system architecture, you push your logic back onto the server side Nothing to do with hypermedia. You can choose to push logic to the server with a single-page app too. > The server side is a trusted computing environment, so you can have complete access to a data store when writing logic there Same. I'm still failing to see a _benefit_ that hypermedia and HATEOAS approach provides, or what problem it solves.
- deniz-a 4y ago
  If you're writing a web app that only works in a browser you control, then no, you won't benefit from hypermedia. The rest of us like search engines being able to index our sites though.
KrugerDunnings 4y ago
The frustrating thing about this post is that it is true and in the bigger scheme of things utterly irrelevant. Yes what is presented here is more restful and it correctly stresses the importance of the client in a proper hyper media application. The thing is no one with the exception of a small number of puritan web developers care about this. I've seen applications where the server responded with the error code 437 for bad requests. Like how could you have gotten that wrong, but they did and it did not matter.
habitue 4y ago
As someone who once bought into the entire HATEOAS thing, and wrote a (somewhat widely used) python library[0] for interacting with HAL+JSON apis, let me be the first to say: Let it die. HATEOAS doesn't solve any problems that we actually have. GraphQL is something that solves the problems we actually have with JSON APIs. Fielding style REST with hypermedia only makes sense for the HTML web where you have a human determining how to navigate from one page to another. If you try to remove hard-coding from your API and make it all navigable by some generic client, you end up just building abstractions and generality that's never needed by anyone. It'll waste a lot of time, and make your frontend developers hate you. Please, let HATEOAS die and let's never mention it again. Thanks [0]: https://rest-navigator.readthedocs.io https://rest-navigator.readthedocs.io
- Groxx 4y ago
  >Fielding style REST with hypermedia only makes sense for the HTML web where you have a human determining how to navigate from one page to another. Yeah, once I realized this, HATEOAS / "strict" REST immediately went into my "nope" bucket. It's pretty much fine for humans and makes some compelling decisions in that context, but it's wildly unusable and unstructured for literally anything else and that makes it almost useless. HTTP verbs and codes are plenty useful, and REST has been co-opted to mean "use verbs and codes correctly" and... I'm OK with that. It summarizes as "follow the patterns that much of the computing world relies on, so you don't break shit everywhere all the time" and that's something absolutely worth understanding and adopting in depth.
- hudon 4y ago
  I don’t know if you’ve used htmx, but it makes one way more productive in building websites that can behave like SPAs without the need for all the junk that one needs to get it going. All you need is html templates and a backend server. No JSX, no client side routing lib, no Node.js, no separate API server, heck coupled with something like Alpine.js you can get very far with little to no JavaScript, too (and it’ll still look and feel snappy). None of all the stuff we’ve been forced to use because of HTML’s incompleteness as hypermedia. The downside to this boost in productivity is when the need for a mobile app comes along, now you need a non-REST API, too. Then you can take out GraphQL or gRPC or something suited for the task. Your mobile client would most likely be using a different surface of the API even if you had one for web clients, so it’s not like you’re wasting much effort here.
fatneckbeard 4y ago
i thought this was about hypercard. boy is there egg on my face!
- eyelidlessness 4y ago
  It’s not not about HyperCard. A HC product is definitely more “hypermedia” than JSON. Granted there are no clients which can use it (I’m sure there’s some esoteric exception, but meh).
  - deniz-a 4y ago
    > there are no clients which can use it ... HyperCard?
ozten 4y ago
A middle ground is having rich UI components that are declaratively driven server side. Some benefits are being able to have three FE codebases in sync with less effort (Website, iOS, Andriod). BFF (Backend for Frontend) is a good starting point.
recursivedoubts 4y ago
Hello, I'm the author, and this is my attempt at explaining why just slapping a "link" property in your JSON response doesn't make for a REST-ful architecture. I think this should be considered good news for JSON API developers: they can set aside REST, HATEOAS and all that noise, and just focus on building good, rich data APIs.
- bradgessler 4y ago
  Lots of people get tripped up by limitations of web browsers. https://hyperview.org/ https://hyperview.org/ should be held up really high to show what’s possible if we think outside of the browser. It looks like it’s optimized for Material UIs, but we can imagine what it might look like for other UIs like Apple, etc. Apple has given us a glimpse of that with Apple TV Markup https://developer.apple.com/documentation/tvml https://developer.apple.com/documentation/tvml. While it’s not a hypermedia client, it does show us what UIs are possible via markup. https://native.live/ https://native.live/ is another glimpse, though the financier of this project has said on Twitter that his company is strongly incentivized to keep it “Elixir only”, so I’m not sure where it puts that project with respect to a SwiftUI hypermedia client.
joeyguerra 4y ago
Yep. The web browser is a hypermedia client. It's hard to build a web browser = it's hard to build a hypermedia client.
alexbezhan 4y ago
I use htmx extensively and I care 0 minutes about what is more RESTful and HATEOS. I don’t care about these terms. And for the author to emphasize these concepts is to shoot himself into foot, because nobody cares about that and it’s not why people use htmx or other html-based libraries.
college_physics 4y ago
I am trying to understand why the negativity towards a design that had been celebrated (in the abstract) for so long and even has a dramatic success (the browser). The argument "it does not solve any problem I have" must be taken seriously for what it implies, but has less serious implications if the problem domain people consider is narrower than what the hypermedia design envisaged two decades ago. This feels a bit like mathematics: expediency, predominant business models driving requirements etc dont change fundamental truths or properties. To say 'i dont need complex numbers' just begs for Fourier to come up with fourier analysis :-)
- bryanrasmussen 4y ago
  >The argument "it does not solve any problem I have" must be taken seriously for what it implies I find it difficult to take it seriously because the people making it do not acknowledge any of the history that has led them to this point. They are in a point where they can say that the architecture that underpins the web does not solve their current problems because they are building things on top of that solution. For a lot of people the OS is a wrapper for the browser and that's it. We could reasonably say for those people the OS does not solve any of their problems, except for the fact that it exists to enable them to have a browser and go to the few places they go to. HATEOAS doesn't solve many developer's problems in the same way because those problems are enabled by sitting on top of the solution that is HATEOAS. Also I can't remember who it was that said it, it was back in the time when people were arguing about SOAP vs. REST which, well whatever, I think it might have been Tim Bray or Paul Prescod and they said in discussing what was needed to build a world wide network for information sharing they were predisposed to accept the arguments of the people who had actually done such a thing.
  - college_physics 4y ago
    > They are in a point where they can say that the architecture that underpins the web does not solve their current problems because they are building things on top of that solution. I am afraid the original web architecture is not really that useful or important for the "web application" model. I mean the basic idea is you ship an entire application in javascript or whatever and then make API calls. The user is never meant to leave the "app" anyway. The rest of the digital universe might as well not exist.
silver-arrow 4y ago
Excellent article that clearly describes the benefits and simplicity of hypermedia applications. We have experienced the benefits of designing our web applications in this manner using htmx. This library, htmx, has been a real lifesaver for our projects. Just to be clear, the author is NOT arguing for some forced quasi HATEOAS in the typical current architecture of JavaScript rich client passing JSON data in RPC fashion over HTTP. Instead, he is stressing the beneficial original hypermedia architecture of the web; that being, server rendered HTML to the hypermedia browser client. Htmx adds much dynamic behavior to such an approach.
code-baker-9000 4y ago
The things that matters matters, when we migrated to HTMX + HyperScript (from backend/frontend separation): increased productivity and less resource. Basically we don't care about philosophy, paradigm, etc. It works, we use it.

85 points by telotortium 4y ago

I seriously thought the conclusion was going to be presenting formated HTML or compact JSON* depending on ACCEPT headers or BSON or graphql

replwoacause 4y ago

I love HTMX. I think it is brilliant.

amw-zero 4y ago

The only actual benefit I've ever been able to come up with for HATEOAS / "true" REST, is that it allows servers to evolve independently from clients. As in, you can change endpoints under the hood, but as long as the names of the hypermedia controls stay the same, the client doesn't actually need to change. That is, it's just a level of indirection based on names. What I'm looking for someone to answer is, when I control both the client and server, why is this a benefit?

ucarion 4y ago
REST as understood by Fielding is useful when you have a highly heterogeneous, connected set of things your clients and servers operate on, like websites or a government intelligence system. These sorts of domains are pretty uncommon. It's far more than just an extra layer of indirection to keep backwards compatibility; in practice, you can't change HTTP-layer APIs regardless of your hypermedia controls. People bookmark things and write curl scripts.
- nerdponx 4y ago
  I'm not entirely sure. Fetching attributes of related entities and pagination are really common operations, and those are natural cases where providing the client with pre-built URLs can make the client's job a lot simpler.
dustingetz 4y ago
tools
webmaven 4y ago
> What I'm looking for someone to answer is, when I control both the client and server, why is this a benefit? If you (and only you, personally) control both the client and the server (and by "control" I mean you can update/deploy them as you please, simultaneously if necessary), you can feel free to use any sort of homebrew efficient binary stateful protocol and format you like, with no consequence. However, the more parties that are involved (co-workers, separate teams, external organizations, etc.), and the less those parties are able/willing to synchronize their efforts over time, the more benefit you will see from aspects of REST and HATEOAS. Most developers aren't working in a domain and environment where the diversity of stakeholders is maximally broad for both the client(s) and server(s), so "going full HATEOAS" is often overkill, but you should still understand it, in the same way that you need to understand why data schemas ideally conform to fourth normal form, even if your production data is denormalized in practice. While some benefits from some REST practices can start accruing even in the single developer situation, simply because there can be costs to coordinating between present-you and various versions of past-you and future-you, and their respective client and server deployments, that only makes a case for partial adoption. By all means, only use the practices and patterns that make sense and solve or avoid a pain point for you in your situation rather than being dogmatic. In that sense, REST and HATEOAS shouldn't be considered in any different light than other aspects of writing software such as external dependencies, or changing the toolchain, or splitting some code into its own library or module, or publishing code as open source; sometimes it makes sense, sometimes not (especially when the costs are concrete and the benefits hypothetical).
recursivedoubts 4y ago
A few benefits of the hypermedia approach are: - It can be a much simpler approach to building an application. As evidence for this fact, consider Contexte's experience moving from react to htmx for their Saas application: https://htmx.org/essays/a-real-world-react-to-htmx-port/ https://htmx.org/essays/a-real-world-react-to-htmx-port/. They reduced their codebase to 1/3rd the size with no reduction in UX, dropped JS dependencies by 95%, etc. Not every project is this amenable to hypermedia, but many are. - Related to this, hypermedia is the "native" architecture of the web, and browsers have a lot of technology built into them for it. htmx is a depenedency-free 12k library because it builds on top of that model. - By adopting hypermedia as your system architecture, you push your logic back onto the server side, where you are free to use whatever programming language you prefer: clojure, python, haskell, etc. This lets you write more code in your preferred programming language and execution environment. - The server side is a trusted computing environment, so you can have complete access to a data store when writing logic there. This is in contrast with the browser, where you can't have unrestricted access to the data store due to the fact that a hostile user can open a console and start manipulating the data store. On the server side, you can just use SQL. On the client side, you can't, without putting your whole data store at risk. There are certainly tradeoffs associated with the hypermedia approach: it doesn't work well in situations when you need to respond quickly to many UI-driven events, it sacrifices representational efficiency for flexibility, etc. There isn't a silver bullet, after all. With htmx I am trying to expand the set of applications for which the hypermedia approach will work, but I have no illusions that it will work for everyone: nothing is right for everything.
- amw-zero 4y ago
  > It can be a much simpler approach to building an application This is not related to hypermedia, this is related to server-rendering vs. client-rendering. Everyone knows that server-rendering saves on some code and JS. This is a tradeoff, for less control over the stateful aspects of the client. > Related to this, hypermedia is the "native" architecture of the web But, that was the text-based web. Hypermedia isn't necessary (or desired) for applications, which the web has moved towards supporting. > By adopting hypermedia as your system architecture, you push your logic back onto the server side Nothing to do with hypermedia. You can choose to push logic to the server with a single-page app too. > The server side is a trusted computing environment, so you can have complete access to a data store when writing logic there Same. I'm still failing to see a _benefit_ that hypermedia and HATEOAS approach provides, or what problem it solves.
deniz-a 4y ago
If you're writing a web app that only works in a browser you control, then no, you won't benefit from hypermedia. The rest of us like search engines being able to index our sites though.

KrugerDunnings 4y ago

The frustrating thing about this post is that it is true and in the bigger scheme of things utterly irrelevant. Yes what is presented here is more restful and it correctly stresses the importance of the client in a proper hyper media application. The thing is no one with the exception of a small number of puritan web developers care about this. I've seen applications where the server responded with the error code 437 for bad requests. Like how could you have gotten that wrong, but they did and it did not matter.

habitue 4y ago

As someone who once bought into the entire HATEOAS thing, and wrote a (somewhat widely used) python library[0] for interacting with HAL+JSON apis, let me be the first to say: Let it die. HATEOAS doesn't solve any problems that we actually have. GraphQL is something that solves the problems we actually have with JSON APIs. Fielding style REST with hypermedia only makes sense for the HTML web where you have a human determining how to navigate from one page to another. If you try to remove hard-coding from your API and make it all navigable by some generic client, you end up just building abstractions and generality that's never needed by anyone. It'll waste a lot of time, and make your frontend developers hate you. Please, let HATEOAS die and let's never mention it again. Thanks [0]: https://rest-navigator.readthedocs.io https://rest-navigator.readthedocs.io

Groxx 4y ago
>Fielding style REST with hypermedia only makes sense for the HTML web where you have a human determining how to navigate from one page to another. Yeah, once I realized this, HATEOAS / "strict" REST immediately went into my "nope" bucket. It's pretty much fine for humans and makes some compelling decisions in that context, but it's wildly unusable and unstructured for literally anything else and that makes it almost useless. HTTP verbs and codes are plenty useful, and REST has been co-opted to mean "use verbs and codes correctly" and... I'm OK with that. It summarizes as "follow the patterns that much of the computing world relies on, so you don't break shit everywhere all the time" and that's something absolutely worth understanding and adopting in depth.
hudon 4y ago
I don’t know if you’ve used htmx, but it makes one way more productive in building websites that can behave like SPAs without the need for all the junk that one needs to get it going. All you need is html templates and a backend server. No JSX, no client side routing lib, no Node.js, no separate API server, heck coupled with something like Alpine.js you can get very far with little to no JavaScript, too (and it’ll still look and feel snappy). None of all the stuff we’ve been forced to use because of HTML’s incompleteness as hypermedia. The downside to this boost in productivity is when the need for a mobile app comes along, now you need a non-REST API, too. Then you can take out GraphQL or gRPC or something suited for the task. Your mobile client would most likely be using a different surface of the API even if you had one for web clients, so it’s not like you’re wasting much effort here.

fatneckbeard 4y ago

i thought this was about hypercard. boy is there egg on my face!

eyelidlessness 4y ago
It’s not not about HyperCard. A HC product is definitely more “hypermedia” than JSON. Granted there are no clients which can use it (I’m sure there’s some esoteric exception, but meh).
- deniz-a 4y ago
  > there are no clients which can use it ... HyperCard?

ozten 4y ago

A middle ground is having rich UI components that are declaratively driven server side. Some benefits are being able to have three FE codebases in sync with less effort (Website, iOS, Andriod). BFF (Backend for Frontend) is a good starting point.

recursivedoubts 4y ago

Hello, I'm the author, and this is my attempt at explaining why just slapping a "link" property in your JSON response doesn't make for a REST-ful architecture. I think this should be considered good news for JSON API developers: they can set aside REST, HATEOAS and all that noise, and just focus on building good, rich data APIs.

bradgessler 4y ago
Lots of people get tripped up by limitations of web browsers. https://hyperview.org/ https://hyperview.org/ should be held up really high to show what’s possible if we think outside of the browser. It looks like it’s optimized for Material UIs, but we can imagine what it might look like for other UIs like Apple, etc. Apple has given us a glimpse of that with Apple TV Markup https://developer.apple.com/documentation/tvml https://developer.apple.com/documentation/tvml. While it’s not a hypermedia client, it does show us what UIs are possible via markup. https://native.live/ https://native.live/ is another glimpse, though the financier of this project has said on Twitter that his company is strongly incentivized to keep it “Elixir only”, so I’m not sure where it puts that project with respect to a SwiftUI hypermedia client.

joeyguerra 4y ago

Yep. The web browser is a hypermedia client. It's hard to build a web browser = it's hard to build a hypermedia client.

alexbezhan 4y ago

I use htmx extensively and I care 0 minutes about what is more RESTful and HATEOS. I don’t care about these terms. And for the author to emphasize these concepts is to shoot himself into foot, because nobody cares about that and it’s not why people use htmx or other html-based libraries.

college_physics 4y ago

I am trying to understand why the negativity towards a design that had been celebrated (in the abstract) for so long and even has a dramatic success (the browser). The argument "it does not solve any problem I have" must be taken seriously for what it implies, but has less serious implications if the problem domain people consider is narrower than what the hypermedia design envisaged two decades ago. This feels a bit like mathematics: expediency, predominant business models driving requirements etc dont change fundamental truths or properties. To say 'i dont need complex numbers' just begs for Fourier to come up with fourier analysis :-)

bryanrasmussen 4y ago
>The argument "it does not solve any problem I have" must be taken seriously for what it implies I find it difficult to take it seriously because the people making it do not acknowledge any of the history that has led them to this point. They are in a point where they can say that the architecture that underpins the web does not solve their current problems because they are building things on top of that solution. For a lot of people the OS is a wrapper for the browser and that's it. We could reasonably say for those people the OS does not solve any of their problems, except for the fact that it exists to enable them to have a browser and go to the few places they go to. HATEOAS doesn't solve many developer's problems in the same way because those problems are enabled by sitting on top of the solution that is HATEOAS. Also I can't remember who it was that said it, it was back in the time when people were arguing about SOAP vs. REST which, well whatever, I think it might have been Tim Bray or Paul Prescod and they said in discussing what was needed to build a world wide network for information sharing they were predisposed to accept the arguments of the people who had actually done such a thing.
- college_physics 4y ago
  > They are in a point where they can say that the architecture that underpins the web does not solve their current problems because they are building things on top of that solution. I am afraid the original web architecture is not really that useful or important for the "web application" model. I mean the basic idea is you ship an entire application in javascript or whatever and then make API calls. The user is never meant to leave the "app" anyway. The rest of the digital universe might as well not exist.

silver-arrow 4y ago

Excellent article that clearly describes the benefits and simplicity of hypermedia applications. We have experienced the benefits of designing our web applications in this manner using htmx. This library, htmx, has been a real lifesaver for our projects. Just to be clear, the author is NOT arguing for some forced quasi HATEOAS in the typical current architecture of JavaScript rich client passing JSON data in RPC fashion over HTTP. Instead, he is stressing the beneficial original hypermedia architecture of the web; that being, server rendered HTML to the hypermedia browser client. Htmx adds much dynamic behavior to such an approach.

code-baker-9000 4y ago

The things that matters matters, when we migrated to HTMX + HyperScript (from backend/frontend separation): increased productivity and less resource. Basically we don't care about philosophy, paradigm, etc. It works, we use it.