At Tue, 24 Oct 2006 22:53:09 +0200,
"Matthew J. Dovey" <[log in to unmask]> wrote:
> 
> When we first discussed Update some time ago, I did a quick summary
> of how it would look mapped to various alternatives to SOAP (REST,
> ATOM, WS-Transfer, WSRF) - the summaries and pros/cons can be found
> at http://www.ceridwen.com/srw/record-update/crud.html

Thanks for writing this. A few remarks:

“Whilst it [REST] has a large following it is not an official
standard.” Rest is an architectural style which is based on a large
number of standard (http 1.1, uris, xml, etc.) There is no standard
for the style because it’s really a style and not something that can
be clarified as “first comes this bit, then this next bit.”

“It isn’t clear that all operations (e.g. PUT and DELETE) should
return any data, i.e. could return a ucp:response” I guess this isn’t
particularly clear but PUT and DELETE can certainly return a response
body.

“To be truely REST, HTTP error codes should be used rather than
srw:diagnostics” I would exchange for “rather than” “in addition to”.
Http response codes should be meaningful and accurate but don’t feel
limited to the granularity of response that they give, it’s perfectly
valid to include some more information in addition.

“Some recordIdentifiers might be difficult to encode as a URL.” I’m
not sure what sort of record ids could not be encoded as a url, unless
your record ids include non ascii characters, in which case you use
IRIs.

“ATOM has both a SOAP and REST API.” There may still be plans to have
a soap-enabled atom publishing protocol but you won’t read about it in
the latest draft. I’m not sure where it’s gone.


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