Seo Master present to you: 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 Team2013, By: Seo Master
