HTTP 内容协商机制

最新推荐文章于 2022-11-28 22:35:32 发布

dangfulin

最新推荐文章于 2022-11-28 22:35:32 发布

阅读量2.9k

点赞数 2

分类专栏： web基础文章标签： http 内容协商

本文链接：https://blog.csdn.net/dangfulin/article/details/123438096

版权

web基础专栏收录该内容

4 篇文章 0 订阅

订阅专栏

内容协商是HTTP协议中用于确定客户端和服务器之间交换资源表示的重要机制。它允许服务器根据客户端的能力和偏好返回最适合的资源版本。主要分为服务器驱动和客户端/代理驱动两种方式。服务器驱动通过请求头中的Accept字段指定可接受的媒体类型，而客户端/代理驱动则涉及额外的请求来获取资源的不同表示。内容协商旨在提高用户体验，但也可能带来缓存效率下降和实现复杂性增加等问题。

摘要由CSDN通过智能技术生成

一，内容协商的基本原则

内容协商是当有资源有多种表示可用时，为给定响应选择最佳表示的过程：

一份特定的文件称为一项资源。整个资源，连同它的各种表现形式，共享一个特定的 URL 。
当客户端想要获取资源的时候，会使用其对应的 URL 发送请求。
服务器通过这个 URL 来选择这个请求指向的资源的某一变体——每一个变体就是资源的一种表现形式——然后将这个选定的表现形式返回给客户端。

二，为什么会有内容协商

同一项资源可以有不同的表现形式，简单来说就是不同的数据格式.

举个比较具体的例子，比如使用这样一个 URL 时：http://127.0.0.1:8000/books/v1，客户端既可以显式地通过指定后缀的方式指定所需要的格式：http://127.0.0.1:8000/books/v1/1.pdf 或者http://127.0.0.1:8000/books/v1/1.html等，也可以通过显式地通过指定关键字的方式指定所需要的格式：http://127.0.0.1:8000/snippets/v1/1?format=xml 或者 http://127.0.0.1:8000/snippets/v1/1?format=json等。

这样显得非常直观，但却并不符合 RESTful URL的定义（RESTful URL的定义本身就是对 HTTP 提供的基础设施的充分利用），也并不一定能让客户端的请求得到真正的满足：万一服务器无法返回该资源的某种特定表示呢？

基于这两点，客户端与服务器在与资源实体的相关的信息交互中，应该做这样几件事：

客户端剥离 URL 中除资源本身之外的格式信息，交由 HTTP 中的基础设施进行实现。
服务器以默认（或者说最佳）的表现形式在响应中返回资源实体。

总之，有这样一些关键看法：

应该充分利用 HTTP 协议提供的特性，减少不必要的自定义行为。
请求不是命令，要什么，就双方协商着来，这样能够屏蔽客户端之间的差异，从而实现长期的 URL 功能。
之所以叫内容协商而不叫格式协商，是因为内容可被视为格式的超集，而不仅仅是具体的媒体类型media_type。

Content Negotiation in RFC 2616
Understanding Content Negotiation in Web API
Why would HTTP content negotiation be preferred to explicit parameters in an API scenario?
Content Negotiation For Web API Longevity

三内容协商机制

客户端和服务器端之间存在多种协商方式，有些已经被逐渐淘汰了。这里只介绍两种最主要的方式：

如果响应的最佳表示是由位于服务器的逻辑进行的，则称为服务器驱动的内容协商。
如果响应的最佳表示是在代理或客户端进行的，则称为代理驱动的内容协商。

1，服务器驱动的内容协商

1，当客户端发送 HTTP 请求时，它可以通过请求头中的 Accept 指定它可以接受的媒体类型。举个例子🌰：

Accept: text/xml, application/xml, application/json

客户端也能指定特殊供应商的媒体类型。举个例子🌰：

application/vnd.ms-excel
application/vnd.sif.v2.studentpersonal+json

客户端可以通过Accept、Accept-Charset、 Accept-Encoding、Accept-Language指定详细的响应要求。

2，服务器接收请求后，根据内容协商规则选择最合适的类型，在设置 Content-Type 以包含实际发送的资源类型、使用的字符集、编码方式、内容语言等信息后返回。
如果客户端发发送的请求不包含 Accept ，则服务器可以自由地提供它认为最好的任何表示。
总之，就是服务器根据客户端的请求头的情况，决定：

在 HTTP 响应中返回一种表示
重定向到包含请求的表示之一的不同 URL
发送 415错误（不支持的媒体类型）

3，客户端接收到响应后，就根据 Content-Type 对响应进行解析。

在这里插入图片描述
即便服务驱动型内容协商机制相对直观，但它存在如下几个缺点：

实际上，服务器可返回它认为合理的一切，而并不完全遵守于客户端的要求。
因为给定的资源需要返回不同的展现形式，共享缓存的效率会降低，而服务器端的实现会越来越复杂。
面对不同的资源请求，可能会导致客户端需要使用越来越复杂的请求头内容。

2，客户端/代理驱动的内容协商

1，客户端首先通过 URL 发送请求。
2，服务器会在遇到模棱两可的请求时返回一个页面，该页面包含指向该资源所有可用表示的链接。
3，客户端合适的链接，再次发送请求。
4，服务器解析请求，设置 Content-Type 指定请求所需要的表示，并返回。
5，客户端接收到响应后，就根据 Content-Type 对响应进行解析。
在这里插入图片描述
在确保内容协商成功率时，这也导致一些问题：

HTTP 标准没有指定用于在可用资源之间进行选择的页面格式，、除了回退到服务器驱动的协商之外，这种方法几乎总是与额外的脚本一起使用：在检查协商标准后， JavaScript 脚本执行重定向。
需要一个额外的请求来获取真正的资源，减慢了资源对用户的可用性。

Content negotiation
Accept 与 Content-Type
Apache HTTP Server Version 2.4 Content Negotiation
Content Negotiation
Content Negotiation in REST
HTTP协议的内容协商