对于使用多种格式的 REST 服务，是否存在普遍接受的默认内容类型？答案

【问题标题】：For REST services that consume multiple formats, is there a generally accepted default Content Type?对于使用多种格式的 REST 服务，是否存在普遍接受的默认内容类型？
【发布时间】：2016-06-24 02:10:12
【问题描述】：

如果您有一个接受多种格式的 REST 服务：

JSON
XML
HTML 表单数据

是否存在广泛接受的“默认”内容类型或：

您可以根据最常见/最常见的用例自行选择
不接受缺失的内容类型，由消费者明确要求

例如，根据 W3C，通过 HTML 进行 POST 的默认内容类型是 application/x-www-form-urlencoded。

【问题讨论】：

标签： rest http mime-types

【解决方案1】：

我强烈建议服务器应该拒绝缺少或不适当的Content-Type 标头的请求。 RFC 7231 有明确的代码：

6.5.13。 415 不支持的媒体类型

415（不支持的媒体类型）状态码表示
源服务器拒绝为请求提供服务，因为有效负载
在目标资源上采用此方法不支持的格式。
格式问题可能是由于请求的指示
Content-Type 或 Content-Encoding，或作为检查的结果
直接数据。

尽管它没有明确提及 missing Content-Type，但这是公认的做法。见：HTTP status code for unaccepted Content-Type in request

【讨论】：

绝对与 HTTP RFC：w3.org/Protocols/rfc2616/rfc2616-sec7.html#sec7.2.1 不一致，因为它表明内容类型是“应该”（不是“必须”），接收者“可能”猜测。不过，我看到你的意见是落在“可能猜到”的No 一边
嗯...看起来 RFC 2616 已被几个取代：RFC7xxx
您引用的新 RFC 7231 仍然包含“应该”和“可能”子句，但包含一堆额外的注释，强烈表明贡献者倾向于“不猜测/嗅探”@987654324 @
如果您将“绝对”转换为“强烈建议”，我会标记您的回答正确，因为它为我指明了新 RFC 的方向。

【解决方案2】：

正如您应该在响应中发送内容类型一样，您也应该期望在请求中有一个内容类型。

另外，期望正确的内容类型是很常见的，例如参见Jira REST API：

确保请求中的内容类型设置为“application/json”，如示例所示。

或Twilio，他们有一个接受的内容类型列表并说：

如果 content-type 标头与媒体不匹配，Twilio 将拒绝该请求。

我很确定Outlook Mail REST API 也需要正确设置。

所以，是的，我会说：“不要接受缺少的内容类型”。

【讨论】：