REST - 内容协商

通常，资源可以具有多个呈现，主要是因为可能存在期望不同表示的多个不同客户端。要求客户提供合适的演示文稿，称为内容协商。

HTTP提供了几种“内容协商”机制 - 当有多个表示可用时，为给定响应选择最佳表示的过程。RFC 2616

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

如果通过位于服务器的算法选择响应的最佳表示，则称为服务器驱动的协商。如果在代理或客户端进行该选择，则其被称为代理驱动的内容协商。

实际上，您不会发现服务器端协商的大量用法，因为这样，您必须对客户期望做出许多假设。几乎无法确定客户端上下文或客户端如何使用资源表示等内容。除此之外，这种方法使服务器端代码变得复杂，不必要。

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

1. 使用HTTP标头进行内容协商

   在服务器端，传入请求可能附加有实体。要确定它的类型，服务器使用HTTP请求标头Content-Type。内容类型的一些常见示例是“text / plain”，“application / xml”，“text / html”，“application / json”，“image / gif”和“image / jpeg”。

   Content-Type: application/json

   类似地，为了确定客户端需要什么类型的表示，使用HTTP头ACCEPT。它将具有Content-Type上面提到的值之一。

   Accept: application/json

   通常，如果Accept请求中不存在标头，则服务器可以发送预配置的默认表示类型。

实现Accept基于头的内容协商是最常用和推荐的方式。

2. 使用URL模式进行内容协商

   另一种将内容类型信息传递给服务器的方法，客户端可以使用资源URI中的特定扩展。例如，客户可以使用以下方式询问详细信息：

   http://rest.api.com/v1/employees/20423.xml
   http://rest.api.com/v1/employees/20423.json

   在上面的情况下，第一个请求URI将返回XML响应，无论第二个请求URI是否将返回JSON响应。

定义首选项

如果Accept标题中可以有多个值。当客户端不确定当时服务器是否存在或支持其所需的表示时，客户端可能希望在接受标头中提供多个值。[ RFC 2296 ]

例如，

Accept: application/json,application/xml;q=0.9,*/*;q=0.8

上面的Accept标题允许您向服务器询问JSON格式。如果它不能，也许它可以返回XML格式（第二级）。如果它仍然不可能，让它返回它可以。

首选项顺序通过q参数定义，值为0到1.如果未指定任何内容，则隐含值为1。