Always an Eye on Performance, Google Adds Partial Responses to Some APIs

APIs are now an integral part of any product offering. Developers have continuously pushed the envelope in terms of the features that they want from APIs and API companies have responded from time to time, paying attention to design, reducing the amount of response data and also using performance tuning tools for APIs. In the light of that, Google expanded a feature that it introduced a year back: partial responses and updates.

Partial response and partial update support was announced for a number of Google APIs at the Google Code Blog. The Google APIs include Tasks, URL Shorteners and several others from this list, naturally available via the Google APIs Discovery API.

The idea is deceptively simple. Partial response algorithm means supplying a fields query parameter to the API that returns data. Typically most APIs return you fields that you might not be interested in. With partial response algorithm, you mention the fields that you want and you only get data for them. This significantly reduces the response Payload and can a key to mobile applications that really need to optimize their performance especially in network calls.

An example of a partial response query from the blog post is shown below: JSON&pp=1&fields=items(title,updated)

The above call queries for all Buzz activities for a user but is only interested in receiving the title and updated fields as specified. The full response was 53KB, while the partial response was 3KB, resulting in data reduction by almost 95%.

The partial update algorithm if you have guessed by now is applying the same concept but for updating information and/or deletion. It uses the HTTP PATCH command in supported API methods to send partial updates to Google API services.  Adding and/or modifying data results in a Merge and if you want to delete the field, all you need to do is set it to null. Refer to the documentation for more details.

It is good to note that developers can try out these algorithms in the Google API Explorer. And if you are a Java or Python developer, client libraries already exist to help you use partial response and partial update. Updates for other client libraries is likely to happen soon.

The concept of partial response and partial update is simple to understand and it is likely that developers shall expect these design philosophy to be built into APIs moving forward. LinkedIn APIs are doing this, too. Given that a large amount of API access is likely to happen from mobile devices and over networks that are patchy at times, the partial response/update feature is probably going to be a necessary feature in API design moving forward.

What are the other features that you would like to see API vendors take in the next revision of their API. While we are on the discussion of API performance, do read up on a performance tuning article that we recently covered.

Be sure to read the next Analytics article: New API Billionaire: Text Extractor Alchemy