Partial Response in RESTful API Design
The idea of using partial response in RESTful API design has been around for quite some time. Google introduced partial response and partial update support in Google Data APIs in 2010. LinkedIn implemented similar ideas in their domain-model based API design back in 2009.
In the last few days I have been implementing this feature in muffin.io apps. I think this feature is so important that it should be supported out of box in all muffin apps. In this post I will explain what is partial response, how to design a clear and intuitive syntax for it, and how it’s implemented in muffin apps.
What is partial response?
The idea of partial response is quite simple — instead of returning full objects in API responses with all the data fields, only a subset of data fields are returned. The benefit is obvious — less data transfered over the network means less bandwidth usage, faster server response, less CPU time spent on the server and client, as well as less memory usage on the client. It’s a rare situation where everybody wins.
In the Google post it was mentioned that using a partial Google Calendar feed reduced the total data transfer by 95% compared to a full Google Calendar feed. That’s a huge amount of savings! I bet many people will burst into excitement if stores offer such deep discounts during Thanksgiving sales. More importantly, a faster and more efficient web saves natural resources and helps to reduce the enormous sins we have committed to Mother Nature.
The design of muffin is all about efficiency, so it’s no surprise that I want to implement this as a standard feature in muffin apps. However, efficiency is not all the reasons that I am excited about using partial response in RESTful API design.
In my opinion, a more important but often overlooked aspect of using partial response in API design is its enormous expressive power. Many of us have struggled to find the right balance between designing a flexible API and keeping the API scheme consistent. For example, a client app might only be interested in a few data fields in an object but tailoring the API for a specific client breaks API uniformity. That’s a dilemma that can be nicely resolved by partial response.
It’s best to illustrate this with an example. Suppose we have an object graph involving dogs and their owners (the code uses Google App Engine’s data modeling):
So a full API response for
GET /dogs would return something like this:
If a client app A needs to know a dog’s name, breed, age, but not
eye_color, we can return a partial response with only those three fields. However, a client app B might require all the fields above. So should we design two APIs or sacrifice the efficiency and always return the full objects?
A better solution is to let the client specify which fields should be returned in an API response. Pause you who read this, and think for a moment of this powerful idea. It passes the control from the server to the client — clients with different requirements can share exactly the same API but the responses are optimized just for the requesting client. On the server side, the API scheme stays uniform and consistent.
Let’s go back to the example. For client A which only needs a dog’s name, breed and age, we can make an API request like this:
However, the idea of partial response goes well beyond this. You really start to see its enormous expressive power when dealing with nested data structures. For example, if another client C want to retrieve information about the dog’s owner as well, the traditional way would be a two step process:
- Make the API call to get a list of dogs —
- For each dog returned, make another API call with the owner id and retrieve information about the owner —
But with partial response we can do it all in one step:
And this is an example of the API response:
Now that is cool. You can generalize this idea even further and retrieve data in deeper levels. But we will stop here.
Design an intuitive syntax
Above you have briefly seen the syntax I used for partial response. This syntax is a bit different from what Google and LinkedIn use. Before delving into why I chose a different syntax, let’s examine the ones used by Google and LinkedIn.
Google’s partial response syntax is inspird by the XPath syntax and goes like this:
This syntax is extremely powerful and goes well beyond what I covered in this post. If you want to see them in action, check out the YouTube API page. In short it does way more than simple filtering but let you specify existential conditions, equality comparison, logical comparison, numerical comparison, and more.
LinkedIn’s partial response syntax looks like this:
I admire Google’s syntax but it’s an overkill for simple services I build, and there is definitely a learning curve for anyone who tries to integrate with the API. LinkedIn’s syntax is closer to what I want but I am not a fan of those colons. A standard
?fields= syntax is easier to read and already familar to every web developer. Thus the syntax I use looks like this:
I think it’s very intuitive and there is literally no learning curve. Just the way it should be.
How to implement
Hopefully I have got you excited about using partial response in API design, but now comes the technical question: how do you implement partial response on your server stack?
In the following I will use Google App Engine as an example, but you can easily adapt these techniques to other server stacks.
First we need a simple parser to parse the
fields in the URL. This is the one I wrote:
Not fancy, but gets the job done.
Now we can implement filter support on all the model classes. Every model class extends from a
BaseModel class, in which a
toJSON method is defined as follows:
You see I still need to deal with some security concerns — throw exceptions if the client is requesting for some prohibited fields — but you get the basic idea.
With all these in place, now you have a nice way to retrieve exactly the data you want, and potentially save many API requests as well.