First, two new functions have been added to the service. One provides access to tops (or popular items) lists. The other provides access to the new materials lists. I believe these are significant-enough additions to the service that they merit the 1.1 version number.

The top items query is scalable by result size and can be paginated, just like the search results. In addition, it can be scoped by material type: books, cd, dvd, or bocd (books on CD). When applied to the AADL XSLT, it looks something like this:

The new items query is similar to the top query in that it can be scaled by material type, size and be paginated. You can also search new items using their subject headings–useful for querying those new knitting books, Ed… It looks something like this:

Second, and probably more importantly, I’ve finally drafted a specification for PatREST which includes an explanation of it’s XML schema and some documentation for it’s various functions. It’s about time, I know. It can be found in the files section, or downloaded here. (PDF)

I’m not going to go in to too much detail about the two new functions in this post because the new documentation contains everything you need to know to get started with them.

When last I wrote about this, it was little more than a working proof-of-concept, but I’ve been working on it a lot this week–partly driven by DaveyP’s experiments and Ed’s tinkering, but mostly because I’ve been planning to do this for a long time now.

So, to cut to the chase:
PatREST now provides an easy, RESTful URI to do searches on quite a few fields. Essentially, you will plug the search key into the URI, followed by the search term. You can also request optional paging for keyword, author searches by appending hits-per-page and page-# to the URI. It looks like this:

http://www.aadl.org/rest/search/[searchkey]/[searchterm]/[hits-per-page]/[page-#]

The following search keys are available:

title
author
callnum
keyword
subject
gvtdocnum
stdnum (ISBN/ISSN)
titlekey
controlnum
barcode
record (Bib #)
bibnum (Bib # – Same as record)
itemnum

Go ahead and try this keyword search. It’ll look something like this:

You’ll notice that the XSLT stylesheet presents it nicely, all the data may not be displayed, but the XML is sound. Go ahead and view source to examine the schema. I’ve departed quite a bit from my original schema in order to provide a little bit of metadata for processing purposes. The XSLT allows you to click on a title which will take you to another RESTful record:

You’ll notice that the URI for this record looks like /rest/record/1035670/ … It’s /rest/record/[bibnum]/. The XSLT allows you to click on either the title or cover image to go to the regular OPAC record. Again, view source for the XML schema. This schema has changed little and you’ll notice that I’m taking advantage of OCLC’s xISBN service.

The real treat in all this, however, is the ability to access your personal records RESTfully. To do this, I make use of the RSS token that is provided to every cardholder who has registered for an online account. This is the token that authenticates RSS readers against our system. It is a 32 character MD5 hash that looks something like “316928e0d260556eaccb6627f2ed657b”. Accessing personal data is as easy as using the following URIs:

For checkouts, you would use /rest/checkouts/[token] (ie http://www.aadl.org/rest/checkouts/316928e0d260556eaccb6627f2ed657b). You’ll then get output at looks something like:

For holds, the URI is /rest/holds/[token]. Output looks like:

Both of those results allow you to click on the bibnum and access the REST record for that item. Again, check the XML schema with your browser (no point in putting it here).

Please hack away at this and send me your comments/suggestions. You’re absolutely correct that it doesn’t adhere to any existing standard, but that’s because I didn’t want it to.

On a slightly less geek-oriented note…

I’ve gone several rounds with Talis’s Richard Wallis before, so I want to call your attention to a post he made the other day in which he suggest that a) DaveyP and I collaborate and b) I/we consider using industry standards. I’d like to respond by saying that Dave and I have been communicating extensively. Ed Vielmetti has been involved as well.

Richard writes:

I encourage John, Dave, and those that follow them to take a look at these standards like we have

I can’t speak for Dave, but I’m very familiar with these standards and so is Ed. I think Richard is completely missing the point of this whole project which is to put a friendly, accessible, and useful development interface into the hands of patrons. Ed offers just a small example of the type of features that existing standards don’t readily make available:

Already there is a lot more useful function in it than you can get in SRU, e.g. permalinks for card records and a sensible way to get item availability.

Bear in mind, that comment was made prior to my work with RESTful holds and checkouts, which, as far as I know, don’t even have a standard XML schema–I don’t think it’s been done before! (I’d love to be corrected on this) This project will also evolve to the point where holds can be placed RESTfully, items renewed, fines paid. It’ll also extend to our other features like checkout history, wifi device management, personal card catalog management. Adding this functionality is not only going to allow the public to develop highly useful applications, but it’ll be a framework by which we ourselves can build new services in-house. Vendor’s obviously haven’t stepped up to this, so we are–and we believe in our patrons. They deserve this kind of access to their public library.