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...
>>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
> 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:
And xml.com this week is full of articles about REST:
> 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)
> 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
I liked his points as well.
More information about the OAI-implementers