Http 使用自定义json内容类型是个好主意吗

我正在设计一个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"
}

此内容类型是帖子有效所必需的，并将作为回复的一部分发送。在我看来，这似乎是一个很好的定义有效负载中应该包含哪些内容的规则的方法

我似乎找不到关于这是一个好主意还是IETF标准允许的好资源

---

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

这肯定是允许的。这是否是一个好主意是另一回事

我的经验法则是，它是一种主要的数据格式，在很多方面都很有用，需要自己识别，并且需要跨许多应用程序进行互操作，当然要给它一种媒体类型

然而，如果它只是API中的一条消息，并且只适用于一种资源（或一种资源“类型”），那么只需使用application/json即可

---

当然是YMMV

这个问题与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"
}

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

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

---

这是一个很好的观点。当然，最大的问题是什么是“主要数据类型”，什么不是。我有一个由我的文档定义的数据类型。。。但是rpcapis总是这样，我很少发现有人使用这种方法来表示他们的数据类型。我想知道这是因为这不是一个好方法，还是因为API实现者通常不考虑这一点。

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