内容协商实现对 XML 的支持

在本节中，我们将讨论 RESTful Web Services 的另一个概念，即内容协商。

内容协商

一个资源可以有多种表示形式，这主要是因为可能有多个客户端期望不同的表示形式。

内容协商是为给定的响应选择最佳表示形式的过程，当存在多个可用表示形式时。 它是 HTTP 的一部分，使得在同一 URI 上提供文档的不同版本成为可能。

在 Web API 中，内容协商在服务器端执行，以确定要使用的媒体类型格式，以便返回来自客户端的传入请求的响应。 内容协商以媒体类型和媒体类型格式化程序为中心。

服务器驱动与代理驱动的内容协商

位于服务器的算法负责选择响应的表示形式，这称为服务器驱动的协商。

由代理负责选择响应的表示形式，这称为代理驱动的内容协商。

因此，大多数 RSET API 实现都依赖于代理驱动的内容协商。 代理驱动的内容协商依赖于使用 HTTP 请求或资源 URI 模式。

使用 HTTP 标头进行内容协商

传入的请求可能附加了一个实体。 为了确定实体类型，服务器使用 HTTP 请求标头 Content-Type。 一些常见的 Content-Type 包括：application/json、application/xml、text/html、images/jpg 等。

HTTP 标头 ACCEPT 用于确定客户端需要哪种类型的表示形式。 它包含一个值，如 Content-Type 中所述。

如果请求中没有标头，服务器可以发送预配置的默认表示类型。

使用 URL 模式进行内容协商

还有另一种方法可以将内容类型信息传递到服务器。 客户端可以在资源 URI 中使用特定的扩展名。 例如，客户端可以请求以下内容

第一个请求 URI 返回 XML 响应，第二个 URI 返回 JSON 响应。

定义首选项

首选项通过 q 参数定义，其值介于 0 和 1 之间。 如果客户端未指定请求标头，则它采用隐式值，即 1。

如果客户端不确定其所需的表示形式，并希望在 Accept 标头中给出多个值。 例如

上面的 Accept 标头允许您向服务器请求 JSON 格式。 如果 JSON 格式不存在，它将查找 XML 格式。 如果 XML 格式不可能，就让它返回它可以返回的格式。

我们目前创建的所有服务都仅适用于 JSON 输入和 JSON 输出。 如果我们想使用 HTTP 标头 application/xml 发送 GET 请求，它将返回状态：406 Not Acceptable。

上面的图片显示 XML 不是有效的 Accept 标头。 让我们看看如何将 XML 格式实现为支持的表示形式之一。

步骤 1：打开 pom.xml 并添加 jackson-dataformat-xml 依赖项。

步骤 2：重新启动应用程序。

步骤 3：打开 REST 客户端 Postman 并通过指定 HTTP 标头 Accept: application/xml 发送 GET 请求。

下图显示了 XML 格式的响应。

类似地，我们可以为特定用户发送 GET 请求。

让我们使用相同的 HTTP 标头发送一个 POST 请求。

• 在“Header”选项卡下，添加 Content-Type: application/xml 和 Accept: application/xml。
• 选择 Body 选项卡。
• 以 XML 格式输入用户的姓名和出生日期。
• 选择 XML 格式 XML (application/xml)。
• 单击 Send 按钮。

我们得到 状态：201 Created。 这意味着用户已成功创建。 现在它可以支持 XML 和 JSON 两种格式。