At Fri, 29 Sep 2006 10:11:14 -0400,
Edward Summers <[log in to unmask]> wrote:
> Yes, but conceivably some of these could be expressed as an update/
> PUT. If you take the red pill and imagine an index as a resource, a
> record could be PUT to the index. New indexes could even be created
> with a POST, etc...
> 
>    curl -X PUT http://loc.gov/index < no9910609.xml
> 
> Or perhaps more interestingly (for some):
> 
>    curl http://loc.gov/no9910609 | curl -X PUT http://loc.gov/index
> 
> and some of these could possibly be seen as a representation of a
> given record or a GET
> 
>    curl http://loc.gov/no9910609/classification

In addition to this fine example, one could simple POST one or more
record URIs to an index URI, saving a lot of round trip data which the
server already has (see my previous message).

> As far as indexes go Brian Cassidy has actually implemented a RESTful
> webservice API to Lucene as lucene-ws [1] and the solr [2] project
> has a somewhat similar API. So I guess in a way there is room for
> another not-really-restful api :-)

> I'm not really familiar with the requirements (especially ones like
> index, cluster, classify) so it's hard for me to say with confidence
> how well the Atom-Publishing-Protocol [3] itself would accommodate
> what you want to do in Update . I can say that:

A few nitpicks:

> - APP allows for records to be created, read, updated and deleted
>   over HTTP.

So does pure HTTP.
 
> - APP has facilities for authentication.

Not yet.
 
> - APP uses HTTP status codes to return diagnostics but I would be
>   surprised if most desired diagnostics could not be mapped to a class
>   of HTTP status codes. The response body could be used to bundle more
>   detailed diagnostics if necessary. I had to review RFC 2616 Section
>   4.3 [4] to see if HTTP allowed for message bodies in error
>   responses.

Agreed, one would need to extend APP in this way to get the sort of
diagnostics that are defined in SRU update.
 
> - APP is able to transport any type of XML encoded record as long as
>   it's well formed.

Agreed, although you have the burden of having to wrap it all in Atom
format messages.
 
> - I'm not entirely sure how well APP would support versioning. It
>   could be expressed in REST of course as a representation of a given
>   record like http://loc.gov/no9910609/version/3 or somesuch.

Agreed, but again this is pure URIs plus an extension to the APP.
 
> If there is genuine interest I could look into this further and
> sketch out some examples. It's true that changing APP will be much
> more difficult than changing a zng webpage at the LoC. But even with
> APP's youthful appearance there is already an example of how to
> extend the protocol [5]

To be technical, this is an extension to the Atom *format*, which is a
current RFC, and not the Atom *protocol*, which is still in draft.

> --so perhaps this isn't as a huge an issue as
> you might imagine. I think the real benefit here is joining a larger
> community of developers and bridging the divide between library
> computing and the web community at large (as Ross and Mike pointed
> out).

I see no reason to rely on the APP draft, which consists in 3/4 parts
of an XML schema for describing collections and workspaces of weblogs,
or the atom format, when you already have a fine format in SRW. The
atompub draft, however, provides a great deal of guidance in how to
create an HTTP based mechanism for the creation and editing of
resources, without the heavy weight of WebDAV, and there is no reason
not to follow the spirit of it.
 
> A real advantage in developing a niche standard instead of using
> something like APP is security through obscurity...which probably has
> some appeal given Update's role :-)
> 
> //Ed

[…]

Best,
Erik Hetzner
--
Erik Hetzner
California Digital Library
510-987-0884