https://htmx.org/essays/hypermedia-apis-vs-data-apis/

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

Generally, I would recommend splitting your data and hypermedia APIs up, so you can take advantage of the features of hypermedia (the uniform interface) and still provide a good data API to clients that want it.

Also, this is pedantic, but a graphql JSON API is almost certainly not REST-ful, in the original sense of that term:

https://htmx.org/essays/how-did-rest-come-to-mean-the-opposi...

https://htmx.org/essays/hateoas/

More essays and other silliness here:

https://htmx.org/essays/

Presumably these hypermedia endpoints are all equally accessible - couldn't the removal of one break another application if the latter app decided to depend on a particular hypermedia snippet from the first?

If there are multiple teams in an org that own HTMX endpoints, aren't the set of endpoints effectively a sort of interface boundary? Or is there a good way of declaring certain endpoints "private" and ensuring they're only fetched from particular applications? (Maybe separate domains for every app?)

you might have two separate apps that maintain their own hypermedia APIs and that, on the server side, then share a data API between each other

the idea is to take advantage of the uniform interface of a hypermedia APIs:

https://htmx.org/essays/hateoas/

but there is an assumption there that the server side gives a client a sensible representation of state

[0]: https://twobithistory.org/2020/06/28/rest.html I misremembered the name, it is actually "fuck it, overload http"

So I use HTMX to make the server requests, using triggers defined in HTMX, replacing a lot of JS code. It's really only with the JSON-based responses that I'm going rogue. HTMX is so elegant, I feel dirty going against the grain.

I certainly didn’t mean to imply REST = GraphQL = grpc. “Data api” vs “hypermedia api” is a distinction that makes sense to me.