Despite how simple it is to support, compressing API traffic is an often-overlooked optimization. In situations where an API returns verbose resources, compressing the payload is a great way to reduce latencies. JSON and XML are highly compressible formats, for example.
APIs targeting mobile applications should pay special attention to improving call latency, as mobile apps are often used in bandwidth-constrained situations (e.g. using a mobile app on your smartphone connected to an airport wifi). One should set aggressive targets for these latencies, in order to maintain a positive user experience. Although UX specialists have many tricks up their sleeves, they can’t hide a 10-second API response time. Can your API always respond in 100ms or less under bad connections? Better?
Layer 7′s Gateways have built-in compression of REST API traffic using gzip compression. Most client-side frameworks also have built-in support for this kind of encoding. The compression is initiated by the requesting application, simply by adding the following HTTP header to its requests:
[urlReq setValue:@"gzip" forHTTPHeaderField:@"Accept-Encoding"]
URL url = new URL(urlString);
HttpsURLConnection conn =
Although the reduced-latency benefit of gzip encoding resources is more pronounced for larger resources and low-bandwidth networks, the compression tradeoff on the client side is negligible. API providers and mobile application developers should consider adopting this mode by default.
In addition to response compression, Layer 7 Gateways also support gzip encoding for request messages. This also provides reduction of latency on the client side when requests contain compressible payloads. For example, consider an HTTP PUT with content-type=application/json. The client application declares the compressed content using the content-encoding http header as part of the request.
‘a’: ‘large and complex json here’
When a Layer 7 Gateway detects that an API requester declares this “preemptive” compression, it will not only automatically decompress the request at the perimeter but also compress the response using the same mechanism by default (if the response has a payload).