Engineering for Serendipity

REST is not enough. 

I just read Steve Vinoski's article "Serendipitous Reuse?" in IEEE Internet Computing magazine.  He makes a great case for why REST is the best approach for integration through the concept of serendipitous reuse.  The goal being to engineer the simplest useful interface for services, which allows the greatest possible opportunities for reuse.  By creating opportunities, then reuse can occur.

Saying "REST is sufficient for enterprise integration" is like saying "TCP/IP is sufficient for sending email."  Yep.  TCP/IP is great, but without SMTP, it is only part of the stack.  Just like internet-scale e-mail requires more than just TCP/IP, Enterprise integration requires more than REST.    Sure, it's part of the stack, and a good thing, but REST doesn't provide a sufficient level of harmony to achieve enterprise integration.

Don't get me wrong.  I love REST. Integration based on REST gives you a great way to share some basic operations and minimize coupling on the operation, but coupling exists in data as well.  Decoupling on the operation is step 1, but without similar decoupling in the data, is a partial answer.

Without a uniform interface for the information, integration based on REST will allow the sharing of operations, but not information.  In short: If you stop at REST, the stack is incomplete.

The missing part is a consistent set of information semantics.  A key part of my push for a shared global integration model is precisely this: information identification standards and the semantics around how information can be used. 

SOA without an information model fails.  I've said that many times. 

REST, without an integration model, is no better.  It is certainly no silver bullet. 

[note: edited: I fixed the reference to the source.  Steve's article was published in Internet Computing Magazine.]

[note: based on feedback, I've clarified some of the text of this post.]

Comments

• Anonymous
  January 09, 2008
  PingBack from http://geeklectures.info/2008/01/09/engineering-for-serendipity/

• Anonymous
  January 10, 2008
  Nick, Yes Virginia, REST is easy; information integration is not! I can't count the number of times before we began standardizing our information model and incorporating this model into our services that I had to sit with the service developer to understand the semantics of the service! and these were our SOAP services. Our REST based services were even less self-documenting and harder to use without sitting side by side with the developer to understand how to consume them. Radovan Janecek in an older post on REST and Contract http://radovanjanecek.net/blog/archives/332.html makes some good points on this subject. Steve

• Anonymous
  January 10, 2008
  +1 Nick.  I've always felt the same thing and can't understand why there isn't more discussion on this.  

• Anonymous
  January 13, 2008
  Nick: first note that the publication was in IEEE Internet Computing magazine, not IEEE Computer magazine. All my columns are published in IC. Don't mistake the fact that my column didn't include much discussion of data issues as implying that data coupling isn't an issue. That particular issue of my column focused entirely on interface coupling and reuse, and I have a word count limit of about 2400 words. Discussing both interface issues and data issues in that amount of space to the depth I want to achieve simply isn't possible. I may discuss the data issue in my next column. I fail to understand your comparison to TCP/IP. Sorry, but it seems to make no sense. There's simply no meaningful comparison that I can understand between what I wrote and your remark there. Technically, REST does not need HTTP, as you claim. HTTP is simply the best-known application of the REST architectural style, but others are certainly possible. And yes, of course coupling exists in the data. Every single time someone talks about the benefits of the uniform interface, almost immediately a detractor argumentatively claims that it doesn't matter because there's still data coupling. That's like claiming that X+Y and X+1 exhibit the same amount of variability when X and Y can be any integer. Clearly, that's wrong, as any graph can show. Similarly, operational and interface coupling are very real, and reducing them as REST does can be a huge win. Unlike many SOA technologies, which as you may know I have many years of experience with, REST clearly separates the format of the interchanged data from the mechanisms by which it's interchanged. Because of this, the data that a service/endpoint/resource accepts and provides can easily be varied based on the needs of the requesting application. A single service or resource can even support numerous formats at the same time if it wishes to do so, rather than being stuck with whatever format the IDL forces, or perhaps worse, being stuck with XML Schema. Now, add to that beneficial separation the fact that there are numerous standardized MIME/media types (http://www.iana.org/assignments/media-types/). There's often a very good chance that your applications' data needs can be met by these standardized formats, helping greatly with the information model you talk about. Instead of just calling for a global information model, why don't you make use of the types already registered at the IANA, and for anything that's missing, submit suitable formats for standardization? You have a far greater chance of achieving what you seek via that avenue than any other that I can think of. And finally, there's no substitute for experience. Unlike many, I have significant hands-on experience with both SOA and REST, and the fact is that I've seen and experienced much greater reuse with REST, partly due to the reasons I outlined in my column. If you'd like to write a counterpoint article explaining how SOA helps you engineer for reuse better than REST does, I'd be more than happy to help you get it published in Internet Computing. Just let me know.

• Anonymous
  January 13, 2008
  Hi Steve, Thank you for your thoughtful reply.  I didn't say, nor did I intend to say, that REST was a bad thing.  Personally, I like REST for its simplicity.  And you are correct that the folks who envisioned SOAP did not take advantage of the commands inherent in the HTTP protocol (Get, Post, ...). If you do not use HTTP, you do not get those standard commands, so I would not be quick to agree that REST is quite as simple without HTTP.  You certainly need SOMETHING to seperate your commands from data. And, of course, the fact that the SOAP folks ignored the HTTP commands does not mean that commands cannot be expressed in SOAP, or that the abilities of REST cannot be modeled in SOAP.   The point I was trying to make is that REST does not make enterprise integration any easier or more sustainable.  If you are trying to create a point-to-point integration, you can certainly slap something together quickly in REST, and therein lies it's appeal.   But if you want to create a data standard that can be reused across an enterprise, with intention for reuse, then it is not better than simply specifying a SOAP interface with a STRING where you pump anything you want into the string. SOAP is only a little bit better.  By requiring the interface to check the data types, you get a small amount of dubious benefit.  I'm not claiming a huge gain for SOAP. I'm just not claiming any roses for REST.  The real problem is in the data. And MIME types won't cut it. Respectfully, --- Nick

• Anonymous
  January 14, 2008
  Nick: Note that I never said or even remotely implied that "REST is...simple without HTTP." REST is an architectural style, and I said that it can be implemented with approaches other than HTTP. For example, you say it could be done with SOAP. To model the abilities of REST in SOAP, you'd first have to get it off of HTTP and onto a transport protocol like TCP, and then add a standard set of operations to give it its own uniform interface, which means that the standard SOAP practice of specifying interface-specific operations would end. You'd have to ensure that all the necessary REST constraints were in place to induce the architectural properties that REST seeks to achieve. I don't think the appeal of REST lies in being able to slap together quick integrations; rather, the appeal is just to opposite. It gives you highly extensible, modifiable, versionable, and reusable integrations. REST is a very well-defined architectural style that when properly applied delivers the beneficial properties it's specifically designed to deliver, and those properties are definitely desirable within the enterprise. Reusability is just one benefit, and vast scalability is another. Read Fielding's thesis for the details, it will truly open your eyes. Contrast that approach with most enterprise architectures, which are completely ad hoc (even when based on 3rd-party middleware) and where a disciplined approach of applying constraints to induce desired properties simply never occurs. To say that REST doesn't help with enterprise integration is to simply misunderstand what REST is and what benefits it can help deliver. In addition to the well-defined properties it gives you, it completely eliminates one of the variables -- the specialized interface -- that inhibits scalability and reuse. You shouldn't be so quick to just sweep it under the rug. Let me ask my standard REST question: have you ever actually used it for a real system? I've found that too many SOA folks are much too quick to dismiss REST, or worse, quick to pretend to speak authoritatively about it and argue vociferously against it despite the fact that they've never actually used it. I'm not talking specifically about you here; rather, there are numerous comments on my blog that back me up here. Also, I spent several years working on WS-* standards in the W3C, where I saw and experienced such detractors first-hand. Since you feel so strongly about MIME types -- an opinion that you didn't explain, BTW -- I again have to inquire: have you ever looked into using MIME types in the manner I suggested? If so, perhaps you could explain in a new blog entry, or better yet in an article you'll submit to Internet Computing, why your assertion is right?

• Anonymous
  January 14, 2008
  The comment has been removed

• Anonymous
  January 14, 2008
  Nick: I appreciate your detailed comments as well. It's refreshing to have an informative discussion with someone over technical matters, even if we don't fully agree, without having things descend into undesirable territory as so many blog- and email-based discussions seem to tend to do. I also thank you for reading my column and thoughtfully commenting on it. Thanks for letting me visit.