On Sep 29, 2006, at 5:02 AM, Rob Sanderson wrote:
> In order to create a full over-the-wire remote information system
> management protocol, there's a lot more actions required than just
> create, replace, delete.
> For example, index/unindex, cluster, classify, transform, etc. etc.
> For this, you need a lot more than the simple http verbs.
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
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 agree that there are existing update mechanisms, and if APP (for
> example, which as Ed pointed out didn't exist when we first looked at
> Update) could fulfill the requirements, then re-inventing the
> wheel, or
> even trying to compete, would be absolutely the wrong thing to do.
> But
> I don't know if our community has enough traction to get the necessary
> changes made, in that regards? I'd welcome further comments on this
> approach :)
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:
- APP allows for records to be created, read, updated and deleted
over HTTP.
- APP has facilities for authentication.
- 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.
- APP is able to transport any type of XML encoded record as long as
it's well formed.
- 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.
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]--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).
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
[1] http://lucene-ws.sourceforge.net/docs.html
[2] http://incubator.apache.org/solr/
[3] http://www.ietf.org/internet-drafts/draft-ietf-atompub-
protocol-10.txt
[4] http://www.ietf.org/rfc/rfc2616.txt
[5] http://www.ietf.org/rfc/rfc4685.txt
|