There are some cases in which access uses a low-throughput line (for example, access from a remote location), or the data required by one request is too large. In such cases, the transmission time can be reduced by compressing the content. However, if a small amount of data is acquired over a high-throughput line, the compression process might cause a bottleneck. Therefore, be sure to compress and transfer the content according to the data capacity.
Note that content compression can be used only when the version of the HTTP protocol is 1.1. The supported encoding methods are gzip and identity. Note that content is not compressed when encoded by using the identity encoding method.
The API client includes the Accept-Encoding header in a request message to report the encoding methods. You can specify multiple encoding methods in the API client and then assign a priority level to each method.
If an asterisk (*) is reported in the Accept-Encoding header, gzip is used as the encoding method.
For example, if you want either the gzip or identity method to be used as the compression method, you can specify the Accept-Encoding header in the request message as follows:
Accept-Encoding: gzip, identity
You can use content compression for all URIs, but the contents are only compressed if the size of the response body exceeds 100 bytes.
If content is compressed, the Content-Encoding header and the Vary header are included in the response message. The Content-Encoding header reports the used encoding method to the client. Similarly, the Vary header reports that the response body was changed because of compression. However, if the encoding method is identity, the response message does not include the Content-Encoding header and the Vary header.
The following shows the Content-Encoding header and the Vary header included in the response message if content is compressed by using the gzip encoding method:
Content-Encoding: gzip Vary: Accept-Encoding