4 ms·

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

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?

withinboredom 3y ago
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.
- simonbarker87 3y ago
  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?
  - withinboredom 3y ago
    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'.
    - monknomo 3y ago
      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
- bpicolo 3y ago
  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>"
  - withinboredom 3y ago
    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.
- simonw 3y ago
  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-control/#other 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.
  - withinboredom 3y ago
    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.
    - simonw 3y ago
      I dropped Accept header support from https://datasette.io/ 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 https://github.com/simonw/datasette/issues/1534
      - withinboredom 3y ago
        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.
suction 3y ago
[dead]

withinboredom 3y ago

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.

simonbarker87 3y ago
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?
- withinboredom 3y ago
  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'.
  - monknomo 3y ago
    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
bpicolo 3y ago
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>"
- withinboredom 3y ago
  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.
simonw 3y ago
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-control/#other 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.
- withinboredom 3y ago
  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.
  - simonw 3y ago
    I dropped Accept header support from https://datasette.io/ 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 https://github.com/simonw/datasette/issues/1534
    - withinboredom 3y ago
      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.

suction 3y ago

[dead]