IONA chief engineer Steve Vinoski, author of one of the most influential CORBA books and a huge number of articles, has written a new column (PDF) for IEEE Internet Computing introducing REST from the perspective of a SOA developer.
In the article, Steve highlights the differences between a design that focuses on explicit contracts for each specific functionality and the uniform interface approach of REST. According to his own blog entry about it, it attempts to explain the benefits that REST brings to the distributed systems picture from the perspective of someone with a lengthy SOA background.
Steve's conclusion:
Unfortunately, many SOA developers are far too quick to dismiss REST tools, because their favorite programming language doesn’t directly support it, or because they believe REST is just HTTP. Even if you believe SOA is exactly the right approach for the applications you develop, truly under- standing REST can help you build more scalable and better performing distributed systems.
Read the full article here.
Community comments
Re: Add the P
by Stefan Tilkov,
Re: Add the P
by Stuart Charlton,
disappointing
by Joost de Vries,
Re: disappointing
by Stuart Charlton,
Re: Add the P
by Stefan Tilkov,
Your message is awaiting moderation. Thank you for participating in the discussion.
Similarly to Steve's article introduction, I can see both sides of the argument, including yours -- if SOA is defined at a higher level, REST is just one way to do it. But looking more closely, CORBA, DCOM, RPC, RMI, WS-* all share "service" (a.k.a. a specific interface with operations) as a concept, while REST is different.
Re: Add the P
by Stuart Charlton,
Your message is awaiting moderation. Thank you for participating in the discussion.
That absolutely would be a SOA. A "transfer vector" is one good way of constraining an object-oriented interface. I'd note that COM/OLE even had "Uniform Data Transfer" and the IDataObject interface to enable uniform communication, like desktop drag & drop between autonomous applications -- one just had to understand the flavour of data.
The areas where I believe COM, CORBA or WS oriented architectures are less designed for scale & evolution than REST architectures are:
I guess a lot of the problem really is that most people are confused on what makes an evolvable, socially scalable, heterogeneously implemented, multi-organization agency SOA - and neither CORBA, nor COM (without OLE), nor SOAP Web Services really give any clear indicators here.
disappointing
by Joost de Vries,
Your message is awaiting moderation. Thank you for participating in the discussion.
Vinoski! IEEE Computing! Reviewed by Doug Lea!
These facts made me anticipate a great article.
After reading the article I felt disappointed.
I've been arguing previously here that REST isn't the answer. So if that didn't stick this reaction won't either. But for the record; here are a few points:
Steve splits the contract between the two parties in an interface contract and a data contract. (In my mind the datatypes are part of the interface, but anyhow)
He posits that if the interface is defined in a concise metamodel (essentially CRUD) that this makes it more manageable (scalable he calls it) to develop and maintain a lot of services. I agree. A concise metamodel is essential. It's just that REST-CRUD is not the right metamodel and essential parts of what has to be expressed essentially about services cannot be expressed in it. These aspects will be pushed into the unspecified data interface or into the unspecified conversational behaviour; into the implicit unspecified protocol that will ride de facto on top of REST.
Of this data interface he writes
Self describing messages would be extremely helpful; but it's a hard problem to solve.
So what does REST offer as self describing messages and what are these agreed-upon standards? If I understand the article correctly these are mime-types
The metamodel that REST uses is media formats as exemplified in MIME types. That's exactly the kind of distinction that in the mainstream SOA world is being recognized as necessary but very insufficient; it's just the 'how' of what you're communicating, not the 'what'.
For a web architecture it is the right distinction since only the 'how' is of concern to browsers, servers etcetera, the 'what' is delegated to the human user. And people are incredible skilled in making sense of these unspecified data. But computer systems are not.
That's why I think REST, being based on distributed hypermedia architecture, is a dangerous architecture for services.
Re: disappointing
by Stuart Charlton,
Your message is awaiting moderation. Thank you for participating in the discussion.
How does one share, analyze, and reuse data if it isn't independent from function? This is effectively an argument that goes back to the RDBMS days...
REST doesn't describe a specific meta-model. If you want a different set of operations, that's perfectly all right -- create a protocol and get people to adopt it. HTTP isn't even really CRUD, and can be extended.
REST is just an argument for uniformity in the semantics of message exchange. That doesn't seem to preclude what you're talking about. Generality is a common software engineering principle. REST just applies it for cases of large-grain networked data transfer in a large-scale, multi-agency hyperlinked information system.
REST is just a style. HTTP is not the end of history, but it's also quite flexible - a lot more than people give it credit for.
If you have something you want to communicate, specify it, and in HTTP, include it as a header. Or, if it's novel, create an extension and include it as a new operation, or response code.
But that's metadata. Application control information is described in content via hyperlinks in a particular context. That's the whole premise of hypermedia. One pushes control into presentation, for action by a human or automated agent.
I believe these REST vs. SOA(P) battles have little to do with technology and a lot to do with their social and political implications.
With HTTP, it's headers and response codes in RFC 2616... which are pretty rich in capabilities (redirects, cache control, protocol upgrading & extension, content negotiation, pre-condition checks, range query, content codings, transfer codings, etc.)
The mainstream SOA world, at least in the WS space, doesn't recognize media-types except as a sideshow. It's typically XML or (if one has an ESB supporting a legacy) proprietary record formats that are used. Mind you, that's quite all right for certain business systems, but not a general infrastructure, unless you're just going to look at SVG's all the time ;)
That's semantics, and it's lacking in every mainstream services-oriented technology. For example, neither XML namespaces, nor XSDs, nor WSDL operations describe 'what' beyond syntax. A WSDL operation is just a description to assist with dispatching to what is typically a tightly coupled interface.
For semantics, one requires a rich description of inter-relationships and constraints within a theoretically sound information model. It also tends to require rule languages and/or description logics. There's a lot of good work in the semantic web space, though that's far from mainstream.
REST isn't about "unspecified" data, it's about loosely coupled composition of standard general-purpose identifiers, standard metadata, standard message exchange protocols, and standard media types. Specify what you need to specify, and try to make it as general applicable as possible. Which has always been good software engineering advice "in the large".