There's quite a conversation going on which those of you interested in SOAP, WSDL, and REST may be interested in.
The conversation is in the comments
to my posting Interoperability vs. Integration
. The commenters are Richard Brown
) and Mark Baker
). Richard and I are in the same department, ISSW
; Mark is an independent consultant, old object war horse like me (although we're actually not that
old), and frequent commenter on my blog.
Their comments on interoperability vs. integration have turned into a comparison and debate between explicitly-declared and strongly-typed interfaces vs. simpler ones that are more implied. Richard likes explicit, Mark likes implicit.
This brings me back to the thread I had back in August on Web 2.0 and comparing SOAP with REST. Looking back, maybe the comparison is more between WSDL and REST, which is what Richard and Mark are debating. Check out Web 2.0: APIs Instead of GUIs
through Which is Most Common: SOAP or REST?
, especially Web Services: REST isn't OO
OO may not have been a good description, but I was trying to describe what Richard is pointing out with WSDL: With explicit interfaces, you get a description of what operations are available and what their parameters and return types are. This is something the compiler can enforce. With implicit interfaces, the caller has to just know what the performer expects.
One difference is that WSDL supports multiple operations at a single address (HTTP URL or JMS queue), whereas REST uses a different URL (HTTP only, I think) for every operation. I tend to prefer multiple operations per URL; to me, that's more OO--a single object whose interface conains many domain-specific, intention-revealing method names.
If I understand what Mark and other REST proponents are describing, they're saying that the advantage of REST's implied-interface approach is that you can change what the performer expects without having to change an explicit interface, one which the caller will then no longer match, so changes are easier and therefore the model is more flexible. But if what the performer expects changes, it seems to me that the caller needs to change accordingly. At least with an explicit interface, the caller can see that what it expects is no longer what the performer supports; with implied interfaces, the invocation stops working but it's not apparent why.
Both approaches support adding
to the interface without needing to change the caller, unless and until the caller wants to invoke the new stuff. But I don't see how either approach enables a caller to keep working if the performer's interface changes
So thus far, I have to side with Richard in this debate. But it's an interesting debate, and I'm glad Richard and Mark are having it and documenting it publicly so that we can all benefit from it. So go check it out; you can even jump in if you'd like.