Mobile API best practice: traffic compression

August 27, 2012

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 mobile app on your smartphone connected to an airport wifi). One should set an aggressive target 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?

The Layer 7 Gateway has built-in compression of REST API traffic using gzip compression. Most client side frameworks have built-in support for this kind of encoding as well. The compression is initiated by the requesting application simply by adding the following HTTP header to its requests:
accept-encoding: gzip

iOS sample:
[urlReq setValue:@"gzip" forHTTPHeaderField:@"Accept-Encoding"]

Android sample:
URL url = new URL(urlString);
HttpsURLConnection  conn = (HttpsURLConnection)url.openConnection();
conn.setRequestProperty("accept-encoding", "gzip");

JavaScript sample:
ajax=new XMLHttpRequest();

Any API traffic flowing through the L7 API Proxy or the L7 Mobile Access Gateway automatically benefits from this compression.

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, the Layer 7 Gateway also supports 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.

PUT /aresource
Content-Type: application/json
Content-Encoding: gzip

[gzip encoded]{
‘a’: ‘large and complex json here’
}[gzip encoded]

When a Layer 7 Gateway detects that an API requester declares this ‘pre-emptive’ 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).

200 OK
Content-Type: application/json
Content-Encoding: gzip

[compressed response]