In the ongoing WSDL vs. REST debate, Steve takes Mark to task for seeming to ignore the data side of the interoperability equation. Steve is right that regardless of whether you write WSDLs or use REST-based approaches, both sides need some understanding of the data being exchanged to be able to interact in any meaningful way. However, in Mark's defense, he has not ignored this part of the problem. He's talked about it a few times, such as in the comments he made over in Ted's blog last October.
Invoking a service or object basically requires an understanding of three pieces of information:
1. Where to send the request.
2. Input data for the request.
3. Output data from the request.
You can view item 1 as a combination of address and operation. With HTTP, this is the URL of the target resource together with the HTTP operation you're invoking, such as GET or POST. Items 2 and 3 are pretty obvious.
Having a fixed, uniform set of operations or verbs ala HTTP greatly reduces the total amount of possible variability for item 1. Since the forms of items 2 and 3 are going be highly variable for pretty much any approach, be it WSDL, REST, IDL, or whatever, the amount of variability for item 1 really matters. Clearly, the chances for interoperability are greater when you know a fixed uniform interface up front vs. having to somehow discover specialized interfaces and adapt to them on the fly.
Comments (5)
That's a nice summary and I agree with the points you make. I have no doubt that adhering to the principle of a constrained interface increases the chances of interop.
What's not clear in my mind is how much simply picking HTTP as your constrained interface buys you without also schematizing/constraining the associated data in some way.
Mark mentioned on my blog that he feels that the concept of an "application protocol" only constrains verbs and not data formats. I think there's a deeper constraint system at work here that governs both verbs and data.
In the Indigo world, we call that thing a "contract".
Posted by Steve Maine | February 9, 2006 1:52 AM
Posted on February 9, 2006 01:52
SteveM - I didn't get what you were talking about wrt data on your blog, but I think I see it now.
I don't think you need a single name to describe, simultaneously, the constraints on APIs and constraints on data. If Indigo does this, that's fine, but I dont see the problem with talking about the two separately. What's most important, I hope you agree, is that the messages remain self-descriptive with respect to the operations and data formats being used.
Posted by Mark Baker | February 9, 2006 12:24 PM
Posted on February 9, 2006 12:24
Don't you think that if there were a single WSDL contract that aimed to be as useful as REST/HTTP is, it would end up supporting a fixed set of operations/verbs and a generic data model (String, xsd:any, byte[] or whatever), too?
(BTW, my domain, innoq dot com, seems to be blocked by your spam filter in both email in URL ... hopefully my previous comments weren't that much off-topic? ;-) )
Posted by Stefan Tilkov | February 9, 2006 2:02 PM
Posted on February 9, 2006 14:02
Mark - I don't really have a problem with talking about the two separately either. It's just that most of the stuff I hear coming out of the REST camp focuses on verbs. So where does the schema side of the constraint picture fit in the REST worldview?
Stefan - yup, agree with you too. WS-Transfer does prety much exactly what you describe. But the xs:any is somewhat problematic, because these Transfer endpoints can rarely understand *all possible* infosets. That's a topic for my own blog, though :)
Posted by Steve Maine | February 10, 2006 12:42 AM
Posted on February 10, 2006 00:42
SteveM - REST, does provide some constraints on the data. For example it requires messages be self-descriptive, which impacts the data. As it relates to XML schemas, this constraint, AIUI, means that if a client is trying to communicate the set of valid/conforming documents to a recipient, that it needs to send the schema document with the message, not just reference it, since any change to the schema would change the meaning of the message. That's why I believe that schemas, as commonly used, aren't RESTful. REST requires - again, in the case where extensibility information needs to be communicated - *self-descriptively* extensible data formats, where just knowing the (standardized) media type tells you all you need to know about what's a valid document and what isn't.
You might be interested in this presentation of mine on this topic;
http://www.markbaker.ca/Talks/2004-xmlself/slide1-0.html
Posted by Mark Baker | February 10, 2006 10:48 AM
Posted on February 10, 2006 10:48