However, I’d be wary of sending a 200 response with a different content type if I specified something in the Accept header your service cannot provide. While it may help an inexperienced developer get ANY response back from your service, it doesn’t really help them submit the correct request unless you have some sort of “notes” field stating “We couldn’t supply any of your specified content types, here is our default.” I’d rather see a 406 response with an appropriate human-readable message. Teach a man to fish, and all that.

For example, if for whatever reason the request contains application/hal+json or text/html and you support only application/json and application/xml. From the RFC spec: “If an Accept header field is present, and if the server cannot send a response which is acceptable according to the combined Accept field value, then the server SHOULD send a 406 (not acceptable) response.”

Given that many APIs are used by developers that can be very new to the API world, they may not be using accept headers properly or understand them. For that reason a good strategy may be to parse and honor the header as best as you can (per most of this post), but have that fallback that returns content rather than a 406. In other words, be liberal with the SHOULD in the RFC spec if you it makes life easier for the less skilled developer, while still serving the developer that is embracing the accept header.