Making APIs Faster: Introducing Partial Response and Partial Update
At Google, we strive to
make the web
faster. Today, we’re proud to take our first big step in making APIs faster by
introducing two experimental features in the Google Data Protocol,
partial
response and
partial
update. Together, partial response and partial update can drastically reduce the
network, memory, and CPU resources needed to work with Google APIs.
It’s easy to understand the benefit of partial response and partial update. Imagine that
you are writing a new Android calendar widget, and you want to display the time and title of
the recently changed events on your Google Calendar. With the old Calendar Data API, you would
request your calendar’s events feed and receive a large amount of information in response --
including lots of extra data like the attendee list and the event description.
With the addition of
partial response, however,
you can now use the
fields query parameter to request only relevant
information -- in this case, event titles and times. Constructing such a request using the
fields query parameter is simple:
GET
http://www.google.com/calendar/feeds/zachpm@google.com/private/full?fields=entry(title,gd:when)By including the
entry argument and specifying
title and
gd:when, this request ensures that
the partial response contains only the title and time for each event, along with a small
amount of wrapping metadata.
But say you want to also enable the widget
to change the time of calendar events. With
partial update, you
can easily accomplish this: simply edit the data you received in the partial response and use
the HTTP
PATCH verb to send the modified data back to the server. The
server then intelligently interprets your
PATCH, updating only the
fields you chose to send. Throughout this entire read-modify-write cycle, the unneeded data
remains server-side and untouched.
Now for a quick demo. If you’re
currently logged into a Google account, compare the size of your
full
calendar feed and your
partial
calendar feed. When we ran this test, our full calendar feed contained 160 kB of
data while the partial feed only contained 8 kB -- the partial response successfully reduced
total data transfer by 95%! Performance enhancements like this are especially apparent on a
mobile device, where every byte of memory and every CPU cycle count. In nearly all clients,
partial response and partial update make it more efficient to send, store, parse, cache, and
modify only the data that you need.
As of today, partial response and
partial update are supported in four Google APIs:
... and we’re planning on
adding support for
most
of the APIs that are built on the
Google Data Protocol soon. Stay tuned
for more information, and if you can’t wait, feel free to lobby for partial update and partial
response in your favorite API’s public support group. And for those of you who’ll be at
Google
I/O this year, be sure to check out the
Google
API sessions that are in store.
Thanks for joining us in our
effort to make APIs on the web as fast and as efficient as possible!
By Kyle Marvin and Zach
Maier, Google Data Protocol Team
