You're not really contradicting the article, or the point of htmx. [1] Json-based Data APIs are for machines to interact with. Don't try to shoehorn REST semant

You're not really contradicting the article, or the point of htmx. [1] Json-based Data APIs are for machines to interact with. Don't try to shoehorn REST semantics onto it, accept and embrace the fact that you are coupling tightly and proceed accordingly. But that still leaves space for Application APIs, where a human drives the client, and in that case REST/HATEOAS semantics work just fine. https://htmx.org/essays/splitting-your-apis/ https://htmx.org/essays/splitting-your-apis/ We went on a wild goose chase trying to recreate a hypermedia client with javascript, contorting xmlhttprequest from an application api into a data api, on an already existing hypermedia client (the browser) because the latter stagnated and failed to fill out its functionality. htmx adds the missing functionality to make the browser a functional hypermedia client.