how to deal with undefined / unprovided content-type in REST

Question

Now that content-type header (defining the request content type) is optional according to HTTP 1.1 specification:

Any HTTP/1.1 message containing an entity-body SHOULD include a Content-Type header field defining the media type of that body. If and only if the media type is not given by a Content-Type field, the recipient MAY attempt to guess the media type via inspection of its content and/or the name extension(s) of the URI used to identify the resource. If the media type remains unknown, the recipient SHOULD treat it as type "application/octet-stream".

my question is

1- if content-type is defined in the REST service swagger file, but the request sent doesn't contain a content-type, shall I consider this a correct request or bad request

2- if content-type is not defined in the REST service swagger file, but the request sent contains a content-type, shall I consider this a correct request or bad request

3- if content-type is defined in the REST service swagger file, but the request sent contains a different content-type, shall I consider this a correct request or bad request (I believe not)

Answer 1

DEFAULT MEDIA TYPE

I prefer to have a default media type when possible. For many endpoints this is JSON. If no content-type header is provided then either fail with a clear message as below:

status: 400
{
  "code": "invalid_content",
  "message": "The content of the request was supplied incorrectly"
}

Alternatively attempt to process the request as JSON. If this fails, also return the same error message.

MULTIPLE CHOICES

If an endpoint allows a user to upload an image, there may be no default. In such a case failing as above makes most sense.

CONSUMER FOCUS

More important than any technical concerns is a consumer focus towards REST clients. This includes documentation and a clear code example on how to call the endpoint, and any error responses that may be returned.

Some API stacks reject requests without a content-type but may also return a poor error response that confuses and blocks client developers.

DESIGN CHOICES

As the HTTP spec indicates, the solution is up to the implementer of the REST endpoint. My personal preference is to completely ignore the content-type header in my code unless there are multiple choices.

Even if the default media type becomes suboptimal in future, I could handle that, either by requiring clients to use a newer content-type or by releasing a new major version of my REST component that uses a different default media type. Changes to behaviour would be published to consumers in release notes.

Answer 2

1- Does the Content-Type header in the request specify the content type of the request body or the desired content type of the response body? Answer -> Content-Type header in the request specify the content type of the request body only

2- Supposing the Content-Type header specifies the content type of the request body, is there another header to specify the desired content type of the response body? Answer -> you have to use:

Accept: <MIME_type>/<MIME_subtype> | <MIME_type>/* | / to specify the desired content type of the response body

Will the response to my request have a Content-Type header or another header to specify the content type of its body (response body)? Answer -> Content-Type: Indicates the media type (e.g. text/html or application/json) of the response sent to the client by the server, this will help the client in processing the response body correctly.