5 ms·

I am probably misunderstanding the article, but as far as I can tell, the two ways discussed are "JSON API like almost everybody does" and "do server-side rende

by dack 3y ago

I am probably misunderstanding the article, but as far as I can tell, the two ways discussed are "JSON API like almost everybody does" and "do server-side rendering and call it the API". Not to say it's wrong to do server-side rendering of the frontend, but I got the impression that the article wanted to make a distinction that I'm not seeing.

recursivedoubts 3y ago
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 3y 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 3y 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 3y 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 3y 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 3y 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

by dack 3y ago

recursivedoubts 3y ago

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 3y 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 3y 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 3y 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 3y 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 3y 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