Response Compression

Compression functionality is currently implemented in Prelive . Production is pending on further testing and consultations as a potential breaking change

Our API is equipped with response compression for all requests when certain requirements are met. This will allow larger responses to be returned to clients, whilst also maintaining fast response times.

Currently it will affect Messages Services that provide the message bodies in response.

The requirements that need to be met in order for Connect to compress a particular response are:

• The size of the response body must be at least 10MB.

• The client request must include an Accept-Encoding header containing one of the following types:

Accept-Encoding Header	Details
gzip	The response will be compressed using gzip.
deflate	The response will be compressed using deflate.
gzip, deflate	The response will be compressed using gzip, as this is our preferred compression scheme.

If any message body raw size is over 10MB and client does not support compression by providing a supported Accept-Encoding header our API could respond with Error, most likely HTTP code 500. Exact result depends on customer implementation.

We recommend making use of the Accept-Encoding header containing compressed forms for all requests if possible, provided that the HTTP client in use can handle compressed payloads. This will ensure response times will be minimised no matter the overall size of the response body. Most modern HTTP clients should handle decompression out of the box, so no extra implementation would be required to read a compressed body.

Now we have also available a dedicated service for quick and easy testing of Compression. More details at Get compressed message for testing