1

If you have a REST service that accepts multiple formats:

  • JSON
  • XML
  • HTML form data

Is there a widely accepted 'default' Content Type or:

  • You pick it yourself based on the most frequent / common use case
  • Don't accept a missing content type, require it explicitly by consumer

For example, according to W3C the default content type for POST via HTML, is application/x-www-form-urlencoded.

Ray
  • 36,097
  • 17
  • 85
  • 129

2 Answers2

1

Just as you should send the content-type in a response, you should also expect to have a content-type in the request.

Also, it's quite common to expect the correct content-type, see Jira REST API for instance:

Make sure the content type in the request is set to 'application/json', as shown in the example.

Or Twilio, where they have a list of accepted content-type and say:

If the content-type header does not match the media, Twilio will reject the request.

And I'm pretty sure that also the Outlook Mail REST API needs it to be correctly set.

So, yes, I'd say:"Don't accept a missing content type".

ChatterOne
  • 2,844
  • 1
  • 13
  • 22
1

I strongly suggest that a server should reject a request that has a missing or inappropriate Content-Type header. RFC 7231 Has an explicit code for such:

6.5.13. 415 Unsupported Media Type

The 415 (Unsupported Media Type) status code indicates that the
origin server is refusing to service the request because the payload
is in a format not supported by this method on the target resource.
The format problem might be due to the request's indicated
Content-Type or Content-Encoding, or as a result of inspecting the
data directly.

Even though it doesn't explicitly mention a missing Content-Type, this is the accepted practice. See: HTTP status code for unaccepted Content-Type in request

Community
  • 1
  • 1
Kylar
  • 7,966
  • 6
  • 41
  • 72
  • Absolutly is at odds with the HTTP RFC: https://www.w3.org/Protocols/rfc2616/rfc2616-sec7.html#sec7.2.1 as it indicates that content type is a 'should' (not 'must'), the receiver 'may' guess. Still, I see your opinion is to fall on the `No` side of "may guess" – Ray Mar 09 '16 at 16:45
  • Hmm... looks like RFC 2616 has been superseded by several: RFC7xxx – Ray Mar 09 '16 at 16:51
  • The new RFC 7231 you refernce still has the 'should' and 'may' clauses, but includes a bunch of additional notes strongly indicating the contributers lean in the directions of 'Not guessing/sniffing' https://tools.ietf.org/html/rfc7231#section-3.1.1.5 – Ray Mar 09 '16 at 16:56
  • if you convert 'absolutely' to just 'strongly suggest' I'll mark you're answer correct as it pointed me in the direction of the newer RFC. – Ray Mar 09 '16 at 16:58