Question

我正在设计一个RESTful API并尝试描述并使文档更清晰我想要声明我的内容类型http标头如下：

Content-Type: application/vnd.mycorp.mydatatype+json

其中mycorp是我公司特有的标识符，mydatatype对每种数据类型都是唯一的。一个例子是：

Content-Type: application/vnd.ford.car+json

{
"manufactured_year": 2000
, "color": "blue"
, "hp": 160
, "model" "Focus"
, "type": "sedan"
}

为了使POST有效并且将作为响应的一部分发送，将需要此内容类型。在我看来，这是一种很好的方法来定义有效载荷内的规则。

我似乎无法找到关于这是一个好主意还是IETF标准甚至允许的好资源。

所以，问题是：哪个更可行，application / vnd.mycorp.mydatatype + json或者只是application / json？

Answer 1

此问题与您的REST API 版本控制密切相关。

内容类型用于定义内容的类型。如果您使用标准内容类型，如

application/json

您告诉客户端该消息是JSON格式的。这对于所有不对其API进行版本控制或仅支持最新版本的Web应用程序来说已足够。如果您要让客户使用不同版本的API，标准内容类型是不够的。请考虑以下情形：

将您的示例作为消息的第1版

Content-Type: application/vnd.ford.carV1+json

{
"manufactured_year": 2000
, "color": "blue"
, "hp": 160
, "model" "Focus"
, "type": "sedan"
}

在某些时候，您决定要使用十六进制代码来表示颜色。因此，您创建类型

的版本2

Content-Type: application/vnd.ford.carV2+json

{
"manufactured_year": 2000
, "color": "0000FF"
, "hp": 160
, "model" "Focus"
, "type": "sedan"
}

当客户要求购买汽车时，指定正确的内容类型，包括版本。这告诉应用程序是将颜色发送为十六进制代码还是名称。

在这里，您要对资源的表示进行版本控制。支持资源表示版本控制的替代方法是将版本添加为自定义标头（同时保持内容类型标准）

Content-Type: application/json
Message-Version: 1.0

Answer 2

绝对是允许的。这是一个好主意是另一个故事。

我的经验法则是，它是一种主要的数据格式，可以用于很多事情，需要自己识别，并且需要在许多应用程序之间进行互操作，绝对可以为它提供媒体类型。

但是，如果它只是API中的一条消息，并且它只对一个资源（或一个资源“类型”）有用，那么只需使用application / json。

当然是YMMV。