[recursivedoubts]

Yeah, that was too short a response, sorry I was bouncing around a lot in the thread.

The essay I linked to somewhat agrees w/your general point, which is that hypermedia is (mostly) wasted on automated consumers of REST (in the original sense) APIs.

I don't think it's a bad thing to split your hypermedia API and your JSON API:

https://htmx.org/essays/splitting-your-apis/

(NB, some people recommend even splitting your JSON-for-app & JSON-for-integration APIs: https://max.engineer/server-informed-ui)

I also don't think it's hard to avoid duplicating your effort, assuming you have a decent model layer:

https://htmx.org/essays/mvc/

As far as efficiency goes, HTML is typically within spitting distance of JSON particularly if you have compression enabled:

https://github.com/1cg/html-json-size-comparison

And is also may be more efficient to generate because it isn't using reflection:

https://github.com/1cg/html-json-speed-comparison

(Those costs will typically be dwarfed by data store access anyway)

So, all in all, I kind of agree with you on the pointlessness of REST purity when it comes to general purpose APIs, but disagree in that I think you can profitably split your application API (hypermedia) from your automation API (JSON) and get the best of both worlds, and not duplicate code too much if you have a proper model layer.

Hope that's more useful.

[cryptonector]

Thanks, I appreciate the detailed response.

> So, all in all, I kind of agree with you on the pointlessness of REST purity when it comes to general purpose APIs, but disagree in that I think you can profitably split your application API (hypermedia) from your automation API (JSON) and get the best of both worlds, and not duplicate code too much if you have a proper model layer.

I've yet to see what I proposed, so I've no idea how it would work out. Given the current state of the world I think devs will continue to write JS-dependent SPAs that use JSON APIs. Grandstanding about the meaning of REST is not going to change that.

[recursivedoubts]

I've built apps w/ hypermedia APIs & JSON APIs for automation, which is great because the JSON API can stay stable and not get dragged around by changes in your application.

As far as the future, we'll see. htmx (and other hypermedia-oriented libraries, like unpoly, hotwire, data-star, etc) is getting some traction, but I think you are probably correct that fixed-format JSON APIs talking to react front-ends is going to be the most common approach for the foreseeable future.

[cryptonector]

If you want JS-lesness and HATEOASnes then maybe if we had an automatic way to go from structured data to HTML... :)

[recursivedoubts]

most structured-data to UI systems I have seen produce pretty bad, generic user interfaces

the innovation of hypermedia was mixing presentation information w/control information (hypermedia controls) to produce a user interface (distributed control information, in the case of the web)

i think that's an interesting and crucial aspect of the REST network architecture

[cryptonector]

What I have in mind is something like this:

1) you write your web page in HTML

2) where you fetch data from a server and would normally use JS to render it you'd instead have an HTML attribute naming the "schema" to use to hydrate the data into HTML which would happen automatically, with the hydrated HTML incorporated into the page at some named location.

The schema would be something like XSLT/XPath, but perhaps simpler, and it would support addressing JSON/CBOR data.

[recursivedoubts]

this sounds like client side templating to me (some annotated HTML that is "hydrated" from a server) but attached directly to a JSON api rather than having a reactive model

if you have a schema then you are breaking the uniform interface of REST: the big idea with REST is that the client (that is, the browser) doesn't know or care what a given end point returns structurally: it just knows that it's hypermedia and it can render the content and all the hypermedia controls in that content to the user

the necessity of a schema means you are coupling your client and server in a manner that REST (in the traditional sense) doesn't. See https://htmx.org/essays/hateoas

REST (original sense) does couple your responses to your UI, however, in that your responses are your UI, see https://htmx.org/essays/two-approaches-to-decoupling/

I may be misunderstanding what you are proposing, but I do strongly agree w/Fielding (https://ics.uci.edu/~fielding/pubs/dissertation/rest_arch_st...) that the uniform interface of REST is its most distinguishing feature, and the necessity of a shared schema between client and server indicates that it is not a property of the proposed system.

[eadmund]

> I think you can profitably split your application API (hypermedia) from your automation API (JSON)

Why split them? Just support multiple representations: HTML and JSON (and perhaps other, saner representations than JSON …) and just let content negotiation sort it all out.

[recursivedoubts]

I tend not to like content negotiation:

https://htmx.org/essays/why-tend-not-to-use-content-negotiat...