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