Collections, queries, and REST

Gustavo Niemeyer wonders about collections, queries, and REST:

Now, we want to implement a feature which allows people to access the list of all recent editions of books in their home library, given that they know the URIs for the books because a client program stored the URIs locally in their machines. How would we go about implementing this? We certainly wouldn’t want to do 200 queries to learn about updates for 200 books which a given person has, since that’s unnecessarily heavy on the client computer, on the network, and on the server. It’s also hard to encode the resource scope (as defined in the book) in the URI, since the amount of data to define the scope (the 200 books in our case) can be arbitrarily large. This actually feels like perfectly fit for an RPC: “Hey, server, here are 200 URIs in my envelope.. let me know what are the updated books and their URIs.” I can imagine some workarounds for this, like saving a temporary list of books with PUT, and then doing the query on that temporary list’s URI, but this feels like a considerably more complex design just for the sake of purity.

The sake of purity? Who are these dreaded purity police, anyhow? And how exactly does someone make a "pure" use of the "Whoopee Cushion of Internet protocols"?

This library application already has one collection, the global one, and presumably exposes a number of useful web resources around it: search forms and feeds of several flavors (changesets and archives). The solution, IMO, is not the temporary query resources Gustavo imagines, but smart, permanent user collection resources. Without these, users have no way to share the collections with others or compare their collections to others, and no way to access their collections when away from their desktop library app. Take a look at LibraryThing, Zotero, or OpenLibrary: each have user collections, of books or articles in the first two cases, and changes to book records in the third. User collections, the states of which are stored on a server, are a must-have feature of any application in this class.

Create a new resource for each user collection that exposes a list of the most recent editions of each book, along with links to the new and currently held editions, formatted using Atom so that you can track updates in a feed reader, and you're all set. Using RPC here seems an attempt to route around a problem that doesn't exist, or worse: routing around a must-have feature.