 |
 |
I have begun creating a MyLibrary Web Services interface, and I think my head is going to explode. See: http://dewey.library.nd.edu/mylibrary/demos/reading-list/web- services/ This past January I attended Open Repositories, 2007. One of my take- aways was that Fedora was becoming popular because it supports a Web Services interface. Given such an interface, programs written in Perl, PHP, etc., can interact with Fedora even though Fedora is written in Java. MyLibrary is written in Perl but increasingly people don't seem to be doing Perl programing. Things like Ruby, PHP, Python, or even ColdFusion seem to be more popular. Yet, I have found that MyLibrary's foundation has proven to be quite useful, and we have been able to use it for an increasing a number of "digital libraries". If I could write a Web Services interface to MyLibrary, then MyLibrary could be supported to a greater degree. Hmmm... I then asked this community for advice. Overwhelmingly I was told to read RESTful Web Services by Leonard Richardson and Sam Ruby. This book strongly advocates exploiting the existing features of HTTP to implement RESTful Web Services. This means URL's are intended to describe information objects, and processes done against these objects are to be specified via HTTP methods: PUT (create), GET (read), POST (edit), DELETE (remove), and HEAD (about). In other words, URL's are NOT to include "actions" or "verbs". This is called "overloaded POST". Apparently URL's such as the following are a no-no: http://example.edu/books/?cmd=delete&id=101 Instead you are expected to send the following HTTP request: DELETE /books/101 http://example.edu/ The reason behind these kinds of RESTful implementations -- called Resources Oriented Architecture -- seems to be simplicity on the client side. If "standard" operations such as read, write, edit, and delete are implemented using PUT, GET, etc., then clients only need to know how to process the data returned from the server. All other negotiations are handled by the HTTP protocol such as authentication and error reporting. Even the content type is handled by HTTP. Send me RDF. Send me ATOM. Send me RSS. Send me XHTML. Send me JSON. The URL above points to my beginnings of read-only RESTful Web Service using ROA. It only supports GET. The URL's created by the script are very readable and easily bookmark-able. The data returned is strict XHTML, as advocated by the book. The content is liberally sprinkled with span elements denoting specific types of values: facet names, term names, term notes, resource notes, resources locations (URL's), patron user names, etc. Once I get all the objects exposed I will work towards delivering the content in additional flavors of data, probably RDF and/or JSON. Once that is done I will implement create, edit, and delete but this will entail authentication. Once that is done I will be able to create any number of MyLibrary instances, configure my Web Services script to expose the additions, and allow I/O against the underlying database via "standard" HTTP using any number of client applications. Wish me luck. In summary, RESTful Web Services using ROA (Resource Oriented Architecture) appears to be a "purist" approach to using the Web. It is challenging to implement because user-based clients do not support PUT and DELETE, but then again, RESTful Web Services are primarily intended for acomputer's consumption, not a human's. It is relatively easy to write [insert your favorite language here] programs that can implement PUT, DELETE, etc. -- Eric Lease Morgan University Libraries of Notre Dame