头部值: application/vnd.api + json

有人能解释一下:

application/vnd.api+json

还有

application/json
70168 次浏览
小开

第一种是特定于 API 的媒体类型。供应商前缀(vnd.)表明它是为这个供应商定制的。+json表明它可以被解析为 JSON，但是媒体类型 应该在 JSON 之上定义了进一步的语义。

第二个只是意味着内容是 JSON。但是，这通常不是很有用，因为它没有定义 JSON 值的含义。

阅读这方面内容的一个很好的起点应该是在 维基百科上，但是如果想了解更多细节，您可以通过 那一页上相应的 RFC 链接来获得。

小开
最佳答案

媒体类型 application/vnd.api+json引用了 JSON API。您可以阅读有关它的 非常详细。

简而言之，JSON API 是一个固执己见、理由充分的 API:

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

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

小开

如果您不确定，可以使用 application/json——它是通用的 MIME 类型，只要求返回的数据是 结构良好的 JSON。

application/vnd.api+json MIME 类型保留用于使用 “ JSON API”协议进行通信。

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

该规范特别定义:

  • 请求的具体形式(即哪些 URL 参数控制排序和分页以及输出中包含的数据) ;
  • 响应中 JSON 文档的具体结构，例如:

文件必须至少包含以下高层成员之一:

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

成员 data和 errors不能在同一个文档中共存。

小开

MIME (MIME)类型(或)媒体类型是一种标准化的方式，用于表示通过互联网传输的文档的性质和格式。它在 IETF RFC 6838中是标准化的。 互联网号码分配局是负责跟踪所有正式 MIME 类型的官方机构。

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

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

它是从“厚 JavaScript”客户端和他们的需求中考虑而创建的，但不是特定于他们的。因此，前缀为 vnd(供应商)。

在 JSON API 上增加几点:

  • JSON API 是一个规范，它定义了一个关于请求和响应的 API 规范。
  • 允许我们创建一个定义良好的结构(如资源关系和它的链接等)
  • 指定 RESTAPI 对 讨厌操作的反应方式。
  • 允许客户端缓存响应。
小开

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

让我们用一个例子来讨论 MIME 版本。

假设我们有一个 人实体，我们的 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 获得适当的响应。请检查以下输出:

Application/vnd.company.api-v1 + json 请求第一版

Application/vnd.company.api-v2 + json 请求第二版

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


提交答案