cloud-test: Batching HTTPS REST requests in App Engine

Google Cloud Platform Blog

Batching HTTPS REST requests in App Engine

Tuesday, September 1, 2015

The HTTPS protocol helps to protect the privacy and integrity of web interactions, so it’s not surprising that many Google Cloud Platform customers want to use it as extensively as Google does. However, there's a cost to establishing an HTTPS connection: setting up the underlying Transport Layer Security (TLS) session on which HTTPS is layered requires an exchange of X.509 certificates and cryptographic operations, which can be time consuming.

It's common to use REST to handle communications between client apps and Google App Engine apps. Naturally, you'd want to batch multiple REST requests into a single HTTPS connection to improve overall performance. Establishing the connection only once for many requests would save you the overhead of setting up connections repeatedly.

Unfortunately, you can’t just use HTTP keep-alive headers to batch requests, because App Engine controls several HTTP headers in incoming requests and removes the Keep-Alive header. This means you don't get a persistent connection, so you can't batch multiple requests on it.

However, there is a better solution. Good old HTTP is not the only game in town anymore. The experimental but widely implemented SPDY protocol, in addition to optimization and server-push features, automatically supports TLS and persistent connections. In fact, with SPDY, all connections are persistent. Even better, the new HTTP/2 protocol applies and further improves upon all the learnings from SPDY, including the features that make batching secure requests a breeze. App Engine automatically uses HTTP/2 or SPDY for all HTTPS traffic, as long as the client also supports either protocol. Fortunately, most browsers, in their latest versions, do support either or both protocols.

As a mobile-app developer, in order to take advantage of HTTP/2 or SPDY to batch HTTPS REST requests to your App Engine app, you may need to code and build your app using a library that supports one or both of these protocols. For Android, you can try Square’s OkHttp library.
On iOS, SPDY is enabled by default, so you shouldn't need to make any changes in your app. If you run into trouble, Twitter’s CocoaSPDY library is still an available and popular option.

SPDY and HTTP/2 are compatible with HTTP(S), so it's easy to use them. In fact, if you have a web application running on App Engine, you're probably already using them. Find out by using SPDY tools, such as the magic Chrome URL about:net-internals/#events.
- Posted by Alex Amies, Technical Account Manager and Alex Martelli, Technical Solutions Engineer