I have just finished building a small web application (for accepting grant proposals) on top of an Atom/AtomPub server (instead of an RDBMS). There are just a few entities: person, proposal, budget item, submitting department. Everything is represented as Atom documents and many-to-one relationships (e.g. proposal has many budget items) are represented w/ atom:link (w/ locally minted rels). POSTS/PUT/DELETES are relationship link aware and do the right thing.
I hit an unanticipated snag with sorting. A submitting department gets to "rank" proposals, so the proposal document has a "departmental rank" attribute. As it stands, to resort a set of proposals (and to present a netflix-queue-like interface for sorting) is incredibly expensive. I ended up doing much of it in javascript, but I still end up PUT-ing each document with it's new rank order. Sorting 10 proposals requires a minimum of 10 requests (and all of the authentication, updating, re-indexing, etc. that entails). Seems like I've hit on two pain points of Atom & REST -- the difficulty of doing partial updates and batch updates. I wonder if anyone has any advice on this. One thought is to have a "feed-view" type of atom:entry that simply lists links to the entries in the preferred order. Updating the rank order would entail PUT-ing just that one entry. It's extrinsic rather than instrinsic sort ordering. But that means I'd have to expose a new URI for the feed that was "aware" of the sort order asserted by the view. I am aware this all could be considered a misuse of Atom/AtomPub (I realize there are MUCH easier ways to build such an app), but it is something of a research project, so any advice on this particular pain point would be appreciated. --peter keane
