内容协商实现对XML的支持 _内容协商实现对XML的支持

本文概述

内容协商
服务器驱动与代理驱动的内容协商
使用HTTP标头进行内容协商
使用URL模式进行内容协商
定义首选项

在本节中, 我们将讨论RESTful Web服务的另一个概念, 即内容协商。
内容协商资源可以具有许多表示形式, 主要是因为可能有多个客户端期望不同的表示形式。
内容协商是在存在多种表示形式时为给定响应选择最佳表示形式的过程。它是HTTP的一部分, 可以在同一URI上提供文档的不同版本。
在Web API中, 在服务器端执行内容协商, 以基于返回来自客户端的传入请求的响应来确定要使用的格式化媒体类型。内容协商以媒体类型和媒体类型格式化程序为中心。
服务器驱动与代理驱动的内容协商服务器上的一种算法为响应选择表示形式, 这称为服务器驱动的协商。
代理选择响应的表示形式, 称为代理驱动的内容协商。
因此, 大多数RSET API实现依赖于代理驱动的内容协商。代理驱动的内容协商依赖于HTTP请求或资源URI模式的使用。
使用HTTP标头进行内容协商传入请求可能具有附加的实体。要确定实体服务器的类型, 请使用HTTP请求标头Content-Type。有一些常见的内容类型是：application / json, application / xml, text / html, images / jpg等。

Content-Type: application/xml

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

Accept: application/json

如果请求中没有标题, 则服务器可以发送预配置的默认表示类型。
使用URL模式进行内容协商还有另一种将内容类型信息传递到服务器的方法。客户端可以在资源URI中使用特定的扩展名。例如, 客户可以请求以下内容：

http://demo.com/product/mobile/samsung/galaxy-s8/functions.xmlhttp://demo.com/product/mobile/samsung/ galaxy-s8/functions.json

第一个请求URI返回XML响应, 第二个URI返回JSON响应。
定义首选项 【内容协商实现对XML的支持】优先级是通过q参数定义的, 该参数的值介于0和1之间。如果客户端未指定请求标头, 则它将采用隐式值, 即1。
如果客户端不确定其所需的表示形式, 并希望在accept标头中提供多个值。例如：

Accept: application/json, application/xml; q=0.7, */*; q=0.5

上面的accept标头允许你向服务器请求JSON格式。如果不存在JSON格式, 它将查找XML格式。如果XML格式不可行, 则让它返回可以的格式。
到目前为止, 我们创建的所有服务仅适用于JSON输入和JSON输出。如果我们要使用HTTP标头application / xml发送GET请求, 它将返回状态：406不可接受。

文章图片
上图显示XML不是有效的accept标头。让我们看看如何将XML格式实现为受支持的一种表示形式。
步骤1：打开pom.xml并添加jackson-dataformat-xml依赖项。
步骤2：重新启动应用程序。
步骤3：打开REST客户端Postman并通过指定HTTP标头Accept：application / xml发送GET请求。