Hacker News Reader

Comment by recursivedoubts | Hacker News Reader

Hypermedia APIs and JSON (Data) APIs are different. I have a few essays up on these differences here:

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/

View on HN

Question about this part of the hypermedia vs data APIs essay: "This new end point is driven entirely by hypermedia needs, not data model needs. This end point can go away if the hypermedia needs of the application change"

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?)

in the sense I'm using, an application is a single functional app: you wouldn't have two applications using a shared URL because that would break the uniform interface

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

Thanks for the reply. I will have to give those essays some thought and revisit. I think some of it may boil down to the type of app, customer, etc. At first blush I’m hesitant to want two apis plus a client at least for my typical (admitedly smaller forms-on-data) type projects. But I do plan to revisit and see. The client template extension may be the gateway drug for me here.

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

I'm aware that I'm abusing the tool, but I wrote a htmx extension that overrides the mimetype and JSON encodes all the parameters. The JSON is decoded into a data bag on the back end. Basically I can do "fuck it over HTTP"[0] with needing close to zero JS. HTMX has been a god-send to me.

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

I did something similar, for a dashboard type of web app that involves a lot of graphs. JS graph APIs pretty much all expect data as JSON-formatted JS variables, not HTML.

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.

Reply on news.ycombinator.com