[OAI-implementers] SOAP-PMH

[Matthew J. Dovey]

REST (and REST-like - since neither OAI-PMH nor SRU is strictly REST)
works better when the client developer (or server developer for that
matter), is happy to deal with a chunk of XML and use their favourite
tools (DOM, SAX, XSLT etc.) to handle the XML.

SOAP works better when the WebService is well typed and parameterised,
and the client developer prefers to have a SOAP toolkit generate an API
(so the client developer never sees XML).

Of course in OAI-PMH (just as in SRW/U) the payload is going to be an
XML representation of the metadata so the developer will still have to
cope with XML even in a SOAP implementation.

REST is a lower entry point in terms of complexity (in that you don't
need REST specific tools - as John mentions a browser will do the job).
SOAP needs toolkits, and at present unless you are using C# or Java,
support can be patchy.

REST services tend to be more forgiving of variance/errors in the XML.
SOAP will give an fault if the XML isn't strictly correct. Again this
makes REST easier to implement in the short term, but can cause problems
long term.

REST is (currently) limited to working over XML, HTTP and using a
request/response model. SOAP, however, is not limited to using XML as
the transport encoding (as the programmer never directly works with the
XML directly, it is very easy to support other encodings, and there is
work on binary compact formats for limited bandwidth devices), is not
limited to HTTP as the transport, and is not limited to the
request/response model (indeed the current Axis and .Net SOAP tools
offer SOAP over message queueing systems).

Matthew Dovey
Oxford University

> On Tue, 7 Dec 2004, Matthew Cockerill wrote:
> 
> > I disagree.
> > 
> > Sure, in functional terms, a SOAP implementation won't 
> offer anything 
> > that isn't available with the current HTTP/GET implementation.
> > That's like saying that HTTP isn't worth supporting because 
> it can't do 
> > anything you can't do with your own ad hoc protocol over TCP/IP.
> > 
> > The reason that HTTP is worth supporting is that there are tools 
> > (browsers, client libraries, proxies etc) that support it.
> > 
> > And the same is true of SOAP. For better or worse, SOAP is the best 
> > supported standard for making web services (such as 
> OAI-PMH) available.
> > And this means that there are high level tools for working 
> with SOAP 
> > available in  essentially all major programming languages.
> > This makes writing robust clients and glue to consume the service 
> > *dramatically* easier. And this in turn will increase uptake of the 
> > service.
> > 
> > Matt
> > 
> > 
> > On 7 Dec 2004, at 21:08, Pete Johnston wrote:
> > 
> > > As Jeff noted a couple of messages upthread, the issue is 
> not SOAP v
> > > OAI-PMH, or search v harvest, but whether an 
> implementation of OAI-PMH
> > > semantics over SOAP offers anything that is not available 
> using the
> > > current implementation over HTTP GET/POST.
> > 
> > 
> > _______________________________________________
> > OAI-implementers mailing list
> > List information, archives, preferences and to unsubscribe:
> > http://www.openarchives.org/mailman/listinfo/oai-implementers
> > 
> 
> 
> _______________________________________________
> OAI-implementers mailing list
> List information, archives, preferences and to unsubscribe:
> http://www.openarchives.org/mailman/listinfo/oai-implementers
> 
>