标头值：application/vnd.api+json

Question

谁能解释一下：

application/vnd.api+json

和

application/json

Answer 1

第一个是 API 特定的媒体类型。供应商前缀 (vnd.) 表示它是为此供应商定制的。 +json 表示它可以解析为 JSON，但媒体类型应该在 JSON 之上定义更多语义。

第二个只是表示内容是 JSON。不过，这通常不是很有用，因为它没有定义 JSON 值的含义。

阅读此内容的一个很好的起点是Wikipedia，但要了解更多详细信息，您可以随时关注that page 上相应 RFC 的链接。

Answer 2

媒体类型application/vnd.api+json 指的是JSON API。你可以阅读它in great detail here。

简而言之，JSON API 是一种自以为是且有充分理由的：

…关于客户端应如何请求资源的规范 获取或修改，以及服务器应如何响应这些 请求。

供应商前缀 (vnd.) 表示它是为此供应商定制的。 +json 表示可以解析为 JSON，但媒体类型应在 JSON 之上定义更多语义。

Answer 3

如果您不确定，请使用 application/json - 这是通用 MIME 类型，只要求您返回的数据是 well-formed JSON。

---

application/vnd.api+json MIME 类型保留用于使用（名称令人困惑的）"JSON API" 协议进行通信。

“JSON API”在此上下文中不是指任何基于 HTTP 和 JSON 的 API。它也不是一个完全指定的 API，而是一个框架，用于构建允许客户端获取和修改相关实体的 API。例如，博客应用程序可以实现符合“JSON API”规范的 API，允许在单个 HTTP 请求中获取给定作者的最后 10 篇文章，以及每篇文章的元数据和 cmets。

规范特别定义了：

• 应形成请求的具体方式（即控制排序和分页的 URL 参数以及输出中包含的数据）；
• 响应中JSON文档的具体结构，例如：

文档必须至少包含以下顶级成员之一：

• data：文档的“原始数据”
• errors：错误对象数组
• meta：包含非标准元信息的元对象。

data 和 errors 成员不得共存于同一个文档中。

Answer 4

多用途 Internet 邮件扩展 (MIME) 类型（或）媒体类型是一种标准化方式，用于指示通过 Internet 传输的文档的性质和格式。它在IETF RFC 6838 中标准化。 互联网号码分配机构 (IANA) 是负责跟踪所有官方 MIME 类型的官方机构。

JSON API 使用的媒体类型是application/vnd.api+json，并且已在 IANA 正确注册。

API+JSON 媒体类型用于提供 JSON 服务的不同 API 之间的互操作性。

它是在考虑“厚 JavaScript”客户端及其需求后创建的，但并非特定于它们。所以，以vnd（供应商）为前缀。

在 JSON API 上再添加几点：

• JSON API 是一种规范，它定义了一个关于请求和响应方式的 API 规范。
• 允许我们创建具有明确定义的结构（如资源 - 关系及其链接等）
• 指定 REST API 应如何响应 CRUD 操作。
• 允许客户端缓存响应。

Answer 5

如果您需要设置以下标题 application/vnd.hmrc.1.0+json

那你应该去

Accept: application/vnd.hmrc.1.0+json

使用 CUrl 你可以运行脚本

$url="https://test-api.service.hmrc.gov.uk/hello/world";
$ch = curl_init();
$curlConfig = array(
    CURLOPT_URL            => $url,
    CURLOPT_HTTPHEADER     => array('Accept: application/vnd.hmrc.1.0+json') 
);

curl_setopt_array($ch, $curlConfig);
$result = curl_exec($ch);
curl_close($ch);

希望对你有帮助！！

Answer 6

这称为MIME 类型版本控制 或内容协商。当您开发 REST API 时，您可能希望将来添加该 API 的不同版本，例如 v1、v2 等，并且我们 API 的不同用户应该能够调用所需的版本。 现在可以有不同的方法来解决这个 API 版本控制问题，例如 URI 版本控制、Parameter 版本控制、Header 版本控制或 MIME 版本控制。

让我们用一个例子来谈谈MIME版本控制。

假设我们有一个 Person 实体，我们的 REST API 用它来响应：

public class Person {

   private String name;
   private String email;

   public Person() {
   }

   public Person(String name, String email) {
       this.name = name;
       this.email = email;
   }

   public String getName() {
       return name;
   }

   public void setName(String name) {
       this.name = name;
   }

   public String getEmail() {
       return email;
   }

   public void setEmail(String email) {
       this.email = email;
   }

}

但我们想要的是我们 API 的调用者应该提及一个版本，并基于此我们将与适当的人作出回应。 下面是我们的 RestController ：

@RestController
public class PersonController {
    
    @GetMapping(path = "/person", produces = "application/vnd.company.api-v1+json")
    public Person getPersonV1() {
        return new Person("Mr. ABC", "abc@gmail.com");
    }

    @GetMapping(path = "/person", produces = "application/vnd.company.api-v2+json")
    public Person getPersonV2() {
        return new Person("Mr. XYZ", "xyz@gmail.com");
    }
}

现在我用不同的版本访问我们的 API 并从 API 获得适当的响应。请检查以下输出：

应用程序/vnd.company.api-v1+json Requesting version 1

应用程序/vnd.company.api-v2+json Requesting version 2

因此，我们可以了解如何使用这种 MIME 版本控制方法对 REST API 进行版本控制。不同的组织使用不同的 API 版本控制方法。