BT

CORBA Guru Steve Vinoski on REST

| by Stefan Tilkov Follow 5 Followers on Jan 02, 2007. Estimated reading time: less than one minute |

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.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Re: Add the P by Stefan Tilkov

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

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:

  • information identifiers that are human readable & dereferencable across organization boundaries (an IOR comes close but is missing the "dereference" piece -- ditto for WS-Addressing EPRs without WS-Transfer )

  • evolution of media types, again across organization boundaries (one would require parametric polymorphism to use an OO term)

  • evolution of control structures, again across organization boundaries (all available state transitions are explained through the protocol -- links, metadata, and context, and the transfer protocol itself is upgradable and extensible)

  • reliability , social scalability, and availability (stateless message exchange, standard safe and/or idempotent operations, visibility of operation semantics, redirects, etc.)



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

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:
A significant advantage of the uniform interface constraint lies in the area of scalability. For a client to correctly interact with a SOA service, it must understand the specifics of both that service?s interface contract and data contract. But for a client to invoke a REST service, it must understand only that service?s specific data contract: the interface contract is uniform for all services.

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
REST therefore promotes the notion of selfdescribing messages, in which representation formats are based on agreed-upon standards and are specified within the messages themselves.
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
Allowing services to handle multiple data formats means clients and services can use appropriate data types for different types of data, such as images, text, and spreadsheets. Such media types are specific forms of REST?s general notion of representation metadata.

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

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)

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...
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.

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.
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.

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.

So what does REST offer as self describing messages and what are these agreed-upon standards?


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.)

What's exactly the kind of distinction that in the mainstream SOA world is being recognized as necessary but very insufficient;


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 ;)

it's just the 'how' of what you're communicating, not the 'what'.


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.

And people are incredible skilled in making sense of these unspecified data. But computer systems are not.


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".

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

4 Discuss
BT