Hacker News Reader

Comment by synergy20 | Hacker News Reader

it does not work well with the ever growing restful API backend services to me.

How so? (no snark, genuine)

Your frontend makes a request to your server, the expectation is that will respond with html.

If you have other services you need to bring in to the mix that responds with JSON then make the request to them from your server, have that parse the JSON in to HTML (most likely some kind of templating system like handlebars) and then send that back to your frontend as html for htmx to handle.

Or am I missing something?

Dear god. Have we forgotten about the ACCEPT header? If you get a request with ACCEPT application/json, return json. If you get one with text/html, return html.

I don't think using the accept header is a good idea.

The main reason is that it doesn't necessarily play well with proxies. Most notoriously, Vary: Accept is not supported by Cloudflare (with the exception of images). This means it's not safe to use the accept header if your site will ever be backed by Cloudflare, as you could end up returning cached HTML to a JSON client or vice-versa.

https://developers.cloudflare.com/cache/concepts/cache-contr...

My other problem with it is that it's not very discoverable - it can be surprising to interact with an endpoint that varies based on the accept header. It's not commonly used, so many developers are unfamiliar with it.

And even if you do understand it, it's still hard to tell which endpoints support Vary and which don't.

Finally: I like to debug things by copying and pasting URLs around. The Accept header doesn't support that kind of communication - you need to share not just the URL but also the accept header you were using when you saw a specific response.

I’m not a fan of vendors “not supporting something” as a reason to not use something. Either get a new vendor, put pressure on the vendor, or ignore the feature you want to use.

I personally don’t care about what cloudflare does because I don’t use them.

The rest is RTFM for whatever API you are calling and you usually have to send auth or cookies anyway, so an accept header isn’t that big of a deal.

I dropped Accept header support from https://datasette.io/ because it's open source software that I build for other people to use, and I knew that it was very likely one of my users would choose to run it behind Cloudflare (or run it on a vendor like Vercel who might have a partnership with Cloudflare).

https://github.com/simonw/datasette/issues/1534

FWIW, WordPress uses the Vary: Accept header for a number of apis and it seems to always work fine behind cloudflare and runs a sufficiently large portion of the internet. But, you're telling me I can hit all these site's public api's that are behind cloudflare and start a DOS by simply sending an uncommon ACCEPT header? Sounds like an easy way to pressure cloudflare to 'do the right thing' if you own a botnet.

Anyway, I guess this is yet another reason to not use cloudflare. Thanks for your comment.

JSON APIs are typically more general. Here, you'll need different endpoints/handling for every flavor of HTML you may show that uses that same dataset. It's not so simple as Accept headers unless you always use exactly the same html, in every context on your site, to represent a "user with ID <foo>"

Not at all. Post a form submission, send back either the same form with errors displayed, or simply return out-of-band updates to error message divs. You can redirect from the response as well using htmx, so if the form submission is successful, you can redirect to a success page ... or simply update a div with a success message.

If you get a request asking for json, you just return a json with the same thing. Not much changes with API design if you were designing the API well in the first place.

Not sure if your “Dear god” is negatively targeted at my comment - I’ll assume it’s a general show of exasperation.

How likely is it every API will adhere to that though?

Yeah, just exasperation. For the longest time, most APIs would return json if you asked for json, or xml if you requested xml. Many older api's still do content negotiation, many gave up because 'xml bad'.

Yeah, I remember a lot of apis that were something like `resource/instance.json` or `resource/instance.xml` and they'd give you `instance` in whatever the requested format was

That's the whole point. Those "restful API backend services" are not really REST-ful. The essay, "How Did Rest Come To Mean The Opposite of REST"[0], explains this better than I ever could in a HN post. Maybe we should stop growing these Data-APIs (returning JSON) and switch back to Hypermedia-APIs (returning HTML).

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

it might not be the right REST, the key point though, is that it's json data instead of html, which asks you do client side rendering instead of server side rendering.

htmx might be great for server side rendering, but for client-side-rendering(SPA) which consumes json data from the backend, I doubt htmx is a good fit, and there are lots of json-api-service(instead of html) these days for client to consume.

Reply on news.ycombinator.com