August 28th, 2012

Mobile API Best Practice: Traffic Compression

Mobile API Traffic CompressionDespite 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:

accept-encoding: gzip

iOS sample:

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

Android sample:

URL url = new URL(urlString);
HttpsURLConnection  conn =

conn.setRequestProperty(“accept-encoding”, “gzip”);

JavaScript sample:

ajax=new XMLHttpRequest();

Any API traffic flowing through theLayer 7′s  SecureSpan API Proxy or SecureSpan 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, 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.

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 “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).

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

[compressed response]

No Comments »

No comments yet.

RSS feed for comments on this post. TrackBack URL

Leave a comment