Email or username:

Password:

Forgot your password?
Simon Willison

I still don't like Accept headers

I just found out if you hit pypi.org/simple/pydantic/ with "Accept: application/vnd.pypi.simple.v1+json" you get back super-useful JSON about that package... but I can't link to a demo because I can't include the Accept header in a link!

Here's a Gist instead: gist.github.com/simonw/8cf8a85

15 comments
Helge Heß

@simon I love accept headers, they get you the most suitable response the client can process. If you want to spoof them, you can easily do that using a proxy?

Simon Willison

@helge the only place I like them is for media files (audio, video, image) where you might want to serve back e.g. a smaller .webp file but only to browsers that support it

For APIs they drive me up the wall, because I'm often doing API research from devices (like my phone) that don't have a convenient terminal to hand

Helge Heß

@simon I think it is useful to have resource variants that are also addressable by URL, like /calendar/x/1.ics vs /calendar/x/1.html or /calendar/x/1.json. But that you can have /calendar/x/1 and have that resource serving the proper thing via Accept, is an HTTP superpower to me.

Simon Willison

@helge I get the theory, but in twenty years of mucking around on the Web I've never actually seen real concrete benefit from APIs that do that - I've just found it frustrating

Helge Heß

@simon Fair, I don't think I ever really relied on content negotiation either 🙈 My opinion is that a good setup should support both, accept and extension based type lookup.

Jon Banafato

@simon There's also a JSON API that doesn't require an accept header documented at warehouse.pypa.io/api-referenc (e.g. pypi.org/pypi/pydantic/json) if you haven't seen that. (Not sure if this has the info you're looking for in the response.)

Simon Willison

@jonafato that's not the same information, sadly - I'm looking for the new "provenance" key

Eric Portis

@simon imo it's good practice for servers to have some kind of URL pattern that overrides the header and triggers equivalent behavior, for times when the URL author wants to do something particular. But in general, the whole purpose of 'em is for the URL author to get out of the way and let the client supply client-specific info (which the URL author *can't* know) to the server.

Thomas Sibley

@simon to me it all comes down to documentation: whether it’s the separate URLs to get non-HTML or the alternate media types Accept’d, docs are necessary.

docs.pypi.org/api/integrity/#g

Sylvain Lesage

@simon cc @jed about explicitly passing a format in the URL vs relying on a header

cc @calpaterson too who relies on it in csvbase

Deepak

@simon a long time ago on Cricinfo we used to support plain text scorecards. All you had to do was change the extension of the page in the url from .html to .txt.

Stefan Eissing

@simon http content-negotiation sucks. It always gets in the way.

Many thanks to the github people who showed how to do good url design.

danbri

@simon yeah the RDF / Linked Data community somehow got itself addicted to content negotiation as a favoured way to publish data views. Horrible!

Go Up