[OAI-implementers] SOAP-PMH

Martijn Faassen faassen at infrae.com
Wed Dec 8 10:07:45 EST 2004


Matthew Cockerill wrote:
>>>Migrating OAI to use SOAP as its transport does seem long overdue...


[I write]
>>Disagreed from one implementer, at least. Having to work with SOAP 
>>would've made this developer less happy...

> I should clarify - I wasn't saying that SOAP should or must be the *only*
> syntax for expressing OAI requests.
> REST has many benefits. A lot of services are  provided with SOAP and REST
> interfaces. 

> And it wouldn't be so difficult to provide a gateway that could support the
> legacy OAI  syntax,  to prevent archive implementers from having to rework
> all their stuff.

Calling the current approach 'legacy' already worries me; XML over HTTP 
is not legacy just yet. Why not provide a SOAP gateway instead if you 
want to support such legacy SOAP interfaces? :)

> But SOAP does have significant traction (again, I would point to
> www.sforce.com as just one example: and note that Salesforce.com is a
> company that *seriously* know what it is doing technically).

I'd say REST has a fair amount of traction as well. The "Architecture of 
the World Wide Web, First Edition" document references and describes it:

http://www.w3.org/TR/webarch/

And xml.com this week is full of articles about REST:

http://www.xml.com/

> And SOAP takes care of all kinds of housekeeping issues that everyone has to
> roll their own version of, when implementing an OAI-PMH client using raw
> http and XML processing.

That's the difficulty with frameworks and tools; they offer power but 
also a risk of complexity, which is hard to hide completely. I think 
most of the housekeeping involving OAI-PHM involves resumption tokens; I 
presume SOAP has some mechanism for batching results? (http 1.1 of 
course also implements a way to batch things, though this is probably 
harder to implement on the server side)

[snip]
> By the way:
> I totally agree with Matt Dovey's points detailing some of the respective
> (in many ways complementary) strengths of REST/REST-like approaches vs
> SOAP.

I liked his points as well.

Regards,

Martijn



More information about the OAI-implementers mailing list