3 ms·

server side rendering (that is, returning HTML) is an API, it's just that it's a hypermedia API (poor hypermedia, can't get no respect) rather than a data API,

server side rendering (that is, returning HTML) is an API, it's just that it's a hypermedia API (poor hypermedia, can't get no respect) rather than a data API, intended to be consumed by a hypermedia client (e.g. a web browser) and revealing/affording further API navigation via hypermedia controls (e.g. links) hypermedia APIs have not proven to be good data APIs, but they have proven to be excellent at surviving change within a larger hypermedia system (like the web) in this article I'm trying to show why, despite the promise of decoupling that comes with a generic JSON Data API, it is hypermedia APIs (with tight server/front end coupling) that survive change better, due to the uniform interface of REST

jsyolo 4y ago
and revealing/affording further API navigation via hypermedia controls (e.g. links) I haven't a hard time understanding the utility of this, the article gives an example (removing ability of transfers), but why would a webpage need those hypermedia controls in the response if they are already encoded in the API of the business logic? for ex: The business logic tells the presentation layer, "if X field is true, disable transfers button".
- recursivedoubts 4y ago
  The presentation layer needs to interpret the business layer information in your example. This couples the two together if, for example, the form of the business data changes. This is in contrast to hypermedia where the client (a browser) simply sees the new hypermedia and renders it. In this case, the client is decoupled from the particulars of the business logic. This is due to the uniform interface of REST. See https://htmx.org/essays/hateoas/ https://htmx.org/essays/hateoas/
wpietri 4y ago
Thanks so much for this article. I have something that I want to try out HTMX on and this really clarified some things for me. I particularly liked the bit about the way that the JSON approach, decoupled in theory, often ends up being tightly coupled in practice, such that you keep having to change both at once. And many places are structured such that you need two people or even two teams to make a single change. That doesn't sound decoupled at all! I'm excited to see how it is to give on that in-practice-imaginary decoupling and try for HATOEAS at the fractions-of-a-page level that HTMX looks to enable.
culturedsystems 4y ago
It's an API for a specific hypermedia client, i.e, a web browser. It's not obvious that it's the best hypermedia API for a different client, for example, a JavaScript application that happens to be running in a web browser.
- recursivedoubts 4y ago
  well, if you are building a hypermedia client, good luck to you https://www.oreilly.com/library/view/restful-web-clients/9781491921890/ https://www.oreilly.com/library/view/restful-web-clients/978... it's not a trivial task though

jsyolo 4y ago

and revealing/affording further API navigation via hypermedia controls (e.g. links) I haven't a hard time understanding the utility of this, the article gives an example (removing ability of transfers), but why would a webpage need those hypermedia controls in the response if they are already encoded in the API of the business logic? for ex: The business logic tells the presentation layer, "if X field is true, disable transfers button".

recursivedoubts 4y ago
The presentation layer needs to interpret the business layer information in your example. This couples the two together if, for example, the form of the business data changes. This is in contrast to hypermedia where the client (a browser) simply sees the new hypermedia and renders it. In this case, the client is decoupled from the particulars of the business logic. This is due to the uniform interface of REST. See https://htmx.org/essays/hateoas/ https://htmx.org/essays/hateoas/

wpietri 4y ago

Thanks so much for this article. I have something that I want to try out HTMX on and this really clarified some things for me. I particularly liked the bit about the way that the JSON approach, decoupled in theory, often ends up being tightly coupled in practice, such that you keep having to change both at once. And many places are structured such that you need two people or even two teams to make a single change. That doesn't sound decoupled at all! I'm excited to see how it is to give on that in-practice-imaginary decoupling and try for HATOEAS at the fractions-of-a-page level that HTMX looks to enable.

culturedsystems 4y ago

It's an API for a specific hypermedia client, i.e, a web browser. It's not obvious that it's the best hypermedia API for a different client, for example, a JavaScript application that happens to be running in a web browser.

recursivedoubts 4y ago
well, if you are building a hypermedia client, good luck to you https://www.oreilly.com/library/view/restful-web-clients/9781491921890/ https://www.oreilly.com/library/view/restful-web-clients/978... it's not a trivial task though