The HTTPS protocol provides for a standard agreement between the client and the server for compression of the server response. The client adds the Accept-Encoding header to the request, indicating the supported compression methods, and the server can compress the response using one of the algorithms. Our API supports the standard gzip algorithm for this method.
Unfortunately, this method is not perfect. First, it allows you to compress only the response, but not the request. Second, many client libraries do not support the bzip2 algorithm, which is more efficient than gzip. To eliminate these shortcomings, our API can use two additional parameters: request_compression and response_compression.
Principle of use
If you need to use compression of the data transferred to the API server, you have to transfer the api_key and request_compression to the request URL with one of the permitted compression algorithms. All other parameters must be encoded using application/x-www-form-urlencoded, compressed using the method specified in the request_compression, and transferred in the body of the POST request.
If you need to use response compression, you have to transfer the additional response_compression parameter, where you have to indicate the desired compression algorithm — either gzip or bzip2. If the server considers it necessary, it will compress the response data using the indicated method. The structure of the compressed response data will be as described in the API documentation. In case of compression using the gzip protocol, the response will have the Content-Type HTTPS header: application/x-gzip, and in case of compression using the bzip2 algorithm, the response will have the Content-Type HTTPS header: application/x-bzip.
|response_compression||Compression method applied to the response from the API server. Possible values: bzip2, gzip.|
|request_compression||Compression method applied to the body of the request to the API server. Possible values: bzip2, gzip.|