2 ms·
I think the `.json` can be solved by looking at the `Accept` header rather than switching the URL
by alex_duf 5y ago
I think the `.json` can be solved by looking at the `Accept` header rather than switching the URL
- ryanbrunner 5y agoFormat via extension is definitely more convenient for debugging though, and there's cases where you want to allow direct browser navigation to a particular format in which case you won't be capable of modifying the Accept header (one I use pretty often is sending users to a .csv version of a page to download the contents.
- simonw 5y agoI was planning to implement that a while ago, but I ran into a MASSIVE blocker on that. It turns out Cloudflare - the CDN I use for a bunch of my projects (and often recommend to others) - ignores the "Vary: Accept" HTTP header in most cases! This means you can't safely put a URL that varies on Accept behind a Cloudflare cache - because there's a risk that the cached copy will be stored in an unexpected format, in a way that affects future traffic. I'm really annoyed about this. Notes on that here: https://github.com/simonw/datasette/issues/1534 https://github.com/simonw/datasette/issues/1534
- zzo38computer 5y agoIt could use the Accept header if there is no extension. For example, if it ends with ".html" then it will display the HTML, if it ends with ".json" then the JSON, and if neither then use the Accept header. Having an extension to override it is useful; when not explicitly specified then it could use the Accept header to do it instead. (Another comment mentions that Cloudflare doesn't work with it, but Cloudflare has a lot of undesirable features anyways, so I do not use it.) Another possibility might be <link rel="data">, in case you want to access data (which could have multiple formats (e.g. CSV, JSON, etc), so could occur more than once) without having the URL already or having to run the web application to do everything.