Comparing data with RESTful API

Question

For a website I am working on defining a RESTful API. I believe I got it (mostly) correct using proper resource URIs and proper use of GET/POST/UPDATE/DELETE.

However there is one point where I can't quite figure out what the proper way to do it "in" REST would be - comparison of lists.

Let's say I have a bookstore and a customer can have a wishlist. The wishlist consists of books (their full Book record, i.e. name, synopsis, etc) and a full copy of the list exists on the client. What would be a good way to design the RESTful API to allow a client to query the correctness of its local wishlist (i.e. get to know what books have been added/removed on the wishlist on the server side)?

One option would be to just download the full wishlist from the server and compare it locally. However this is quite a large amount of data (due to the embedded content) and this is a mobile client with a low-bandwidth connection, so this would cause a lot of problems.

Another option would be to download not the whole wishlist (i.e. not including book infos) but only a list of the books' identifiers. This would be not much data (compared to the previous option) and the client could compare the lists locally. However to get the full book record for newly added books, a REST call would have to be made for every single new book. Again, as this is a mobile client with bad network connectivity, this could be problematic.

A third option and my favorite, would be that the client sends its list of identifiers to the server and the server compares it to the wishlist and returns what books were removed and the data for books that were added. This would mean a single roundtrip and only the necessary amount of data. As the wishlist size is estimated to be less than 100 entries, sending just the IDs would be a minimal amount of data (~0.5kb). However I don't know what kind of call would be appropriate - it can't be GET as we are sending data (and putting it all in the URL does not feel right), it can't be POST/UPDATE as we do not change anything on the server. Obviously it's not DELETE either.

How would you implement this third option?

Side-question: how would you solve this problem (i.e. why is option 3 stupid or what better, simple solutions may there be)?

Thank you.

P.S.: A fourth option would be to implement a more sophisticated protocol where the server keeps track of changes to the list (additions/deletes) and the client can e.g. query for changes based on a version identifier or simply a timestamp. However I like the third option better as implementation-wise it is much more simpler and less error-prone on both client and server.

Answer 1

There is nothing in HTTP that says that POST must update the server. People seem to forget the following line in RFC2616 regarding one use of POST:

• Providing a block of data, such as the result of submitting a form, to a data-handling process;

There is nothing wrong with taking your client side wishlist and POSTing to a resource whose sole purpose is to return a set of differences.

POST /Bookstore/WishlistComparisonEngine

Answer 2

The whole concept behind REST is that you leverage the power of the underlying HTTP protocol.

In this case there are two HTTP headers that can help you find out if the list on your mobile device is stale. An added benefit is that the client on your mobile device probably supports these headers natively, which means you won't have to add any client side code to implement them!

If-Modified-Since: check to see if the server's copy has been updated since your client first retrieved it Etag: check to see if a unique identifier for your client's local copy matches that which is on the server. An easy way to generate the unique string required for ETags on your server is to just hash the service's text output using MD5.

You might try reading Mark Nottingham's excellent HTTP caching tutorial for information on how these headers work.

If you are using Rails 2.2 or greater, there is built in support for these headers.

Django 1.1 supports conditional view processing.

And this MIX video shows how to implement with ASP.Net MVC.

Answer 3

I think the key problems here are the definitions of Book and Wishlist, and where the authoritative copies of Wishlists are kept.

I'd attack the problem this way. First you have Books, which are keyed by ISBN number and have all the metadata describing the book (title, authors, description, publication date, pages, etc.) Then you have Wishlists, which are merely lists of ISBN numbers. You'll also have Customer and other resources.

You could name Book resources something like:

/book/{isbn}

and Wishlist resources:

/customer/{customer}/wishlist

assuming you have one wishlist per customer.

The authoritative Wishlists are on the server, and the client has a local cached copy. Likewise the authoritative Books are on the server, and the client has cached copies.

The Book representation could be, say, an XML document with the metadata. The Wishlist representation would be a list of Book resource names (and perhaps snippets of metadata). The Atom and RSS formats seem good fits for Wishlist representations.

So your client-server synchronization would go like this:

GET /customer/{customer}/wishlist
for ( each Book resource name /book/{isbn} in the wishlist )
    GET /book/{isbn}

This is fully RESTful, and lets the client later on do PUT (to update a Wishlist) and DELETE (to delete it).

This synchronization would be pretty efficient on a wired connection, but since you're on a mobile you need to be more careful. As @marshally points out, HTTP 1.1 has a lot of optimization features. Do read that HTTP caching tutorial, and be sure to have your web server properly set Expires headers, ETags, etc. Then make sure the client has an HTTP cache. If your app were browser-based, you could leverage the browser cache. If you're rolling your own app, and can't find a caching library to use, you can write a really basic HTTP 1.1 cache that stores the returned representations in a database or in the file system. The cache entries would be indexed by resource names, and hold the expiration dates, entity tag numbers, etc. This cache might take a couple days or a week or two to write, but it is a general solution to your synchronization problems.

You can also consider using GZIP compression on the responses, as this cuts down the sizes by maybe 60%. All major browsers and servers support it, and there are client libraries you can use if your programming language doesn't already (Java has GzipInputStream, for instance).