Meh. Too many ways to solve the same problem results in bugs and security issues. There is no case where you need to use the Accepts header, you can just put that info in the URL instead.
Some effort to clean up the useless and duplicate features would be good.
Well as you're quite interested in APIs: the accept header is a fantastic way to version a REST API, and even has a built in way to handle clients that can talk to multiple versions of the same API.
Your app could request just 'application/vnd.foo.v1+json' from an API and if it's a centralised service that may be fine.
If the API your app talks to is something that's deployed to customers, or rolls out to regions incrementally or whatever, and thus can be at different versions, you need a way to handle that: the Accept header has you covered.
Everyone does this by putting /v1/ in the api url. It's massively more visible, gets logged properly, and isn't annoying to request from tools like curl.
> Everyone does this by putting /v1/ in the api url
URLs are opaque identifiers that only have meaning to the server that generated them. This makes any meaning implicit, where the accept header is an explicit and documented part of the interface. Maybe not much difference in practice for code you've interacted with, but that doesn't mean no difference at all.
If curl has trouble setting headers, that's a curl problem.
You saying "no one needs that" doesn't mean it doesn't do more than some arbitrary url parameter or path segment. It means you're choosing not to use it.
An API can return JSON, XML, HTML microformats, maybe even a binary encoding of some kind, possibly more down the road. All of these are serialized formats for objects.
Of course you can have a unique URL for each format and avoid the accept header, just like you don't technically need more than GET and POST methods.
The only time you'd ever want to do this is for image and video formats. And HTML has built in support for this in the picture and video tags. Otherwise this sounds nonsensical.
What kind of situation would you ever have a request like "Uh I want json the most but XML could work". Either the backend serves it in a format or not, just directly request what you want.
XML, JSON, Protobuf can all be used as object serialization formats. It's not nonsensical at all for an endpoint to offer choice as to what serialization format a client may want to use. It's not common, but that doesn't mean nonsensical.
URLs are much longer, harder to remember and harder to communicate than accept header values. It also unnecessarily complicates the API. It also relies on out-of-band/non-standardized information to know which URL returns which format, where the accept headers is in-band/standardize information for specifying the return format. Seems like there are more multiple advantages.
Some effort to clean up the useless and duplicate features would be good.