REST资源表示压缩

REST API可以以多种格式返回资源表示，例如XML，JSON，HTML甚至纯文本。所有这些形式都可以压缩到较少的字节数，以节省网络带宽。不同的协议使用不同的技术来启用压缩并通知客户端有关压缩方案 - 以便客户端可以在使用表示之前对其进行解压缩。

压缩与加密一样，是传输中的表示，在客户端可以使用表示之前必须撤消。

HTTP是最广泛使用的REST协议 - 所以我以HTTP特定响应压缩为例。

压缩相关请求/响应标头

接受编码Accept-Encoding

在请求资源表示时 - 以及HTTP请求，客户端发送一个Accept-Encoding标头，说明客户端理解的压缩算法类型。

对于这两个标准值Accept-Encoding是压缩和gzip的。

带accept-encoding标题的示例请求如下所示：

GET        /employees         HTTP/1.1
Host:     www.domain.com
Accept:     text/html
Accept-Encoding:     gzip,compress

接受编码的其他可能用途可能是：

Accept-Encoding: compress, gzip
Accept-Encoding:
Accept-Encoding: *
Accept-Encoding: compress;q=0.5, gzip;q=1.0
Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0

如果Accept-Encoding请求中存在字段，并且服务器无法根据Accept-Encoding标头发送可接受的响应，则服务器应该发送带有406（Not Acceptable）状态代码的错误响应。

内容编码Content-Encoding

如果服务器了解Accept-Encoding中的一种压缩算法，则可以使用该算法在提供表示之前压缩该表示。成功压缩后，服务器通过另一个HTTP头即可知道编码方案的客户端Content-Encoding。

200 OK
Content-Type:     text/html
Content-Encoding:     gzip

如果请求消息中的实体的内容编码对于源服务器是不可接受的，则服务器应该响应状态代码415（不支持的媒体类型）。如果已对实体应用了多个编码，则必须按照应用顺序列出内容编码。

请注意，无论是否请求压缩，请求和响应的原始媒体类型都不会受到影响。

压缩可以节省大量带宽，而且额外的复杂性成本非常低。此外，您可能知道大多数Web浏览器会自动从网站主机服务器请求压缩表示 - 使用上面的标题。

参考文献：

https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.11
https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.3