Steve Vinoski's Blog

The following is excerpted from the full Call for Chapters on REST:

REST has gained popularity not only as a lightweight approach for Web Service development, but it also often used to denote a loosely coupled and Web-friendly approach to design Service-Oriented Architectures. In this book we gather contributions on applying REST beyond public Web services (e.g., in pervasive computing applications, cloud computing environments and integrated enterprise architectures) and on results of recent research studies for doing so. The goal is to go beyond the basic understanding of what REST is about as an architectural style and collect emerging and established design patterns to provide valuable guidance for the reader. The book will both give a clear, principled description of REST and show how it has made an impact in the state of the practice as well as provide an outlook on ongoing research advances. Readers will find a good starting point for making sense of REST, its design constraints, advantages and disadvantages, as well as a broad collection of novel practical application case studies where using REST has made a difference. The book is intended for service designers, information systems architects and anyone interested in learning the current state of research and application of the REST architectural style.

Please see the full call for details. I look forward to helping review your submissions for this book, especially from those of you focused on submitting interesting RESTful application case studies.

Eric Newcomer gives us his take on my recent articles (1, 2, 3, 4) and blog postings (1, 2, 3, 4) about RPC, REST, and programming languages:

Anyway, after carefully reading the article and blog entries, I believe Steve is not against RPC per se. He wants people to think before just automatically using it because it’s convenient.

Exactly!

Also spot on are the following postings:

• Bill de hÓra: Patterns of Web Architecture
• Three postings from Stu Charlton:
  • Convenience, Correctness, and Network Interactions
  • Can technology progress?
  • On changing industry mindsets

The beauty common to all these postings is the breadth, depth, and variety of thinking and reasoning they present. There’s a lot to read, but if you’re interested in critical thinking about the design and construction of distributed systems I encourage you to read them all the way through, including the comments, and to follow the links they offer as well.

Reusability is often promoted not only as a goal but also as a feature of all kinds of software architectures, designs, and systems. For example, in the CORBA, WS-*, and SOA worlds I formerly haunted, everyone spoke nonchalantly of reuse as if it were a given. You were supposed to simply identify the objects or services required to support your business processes, and then specify their interfaces. Then, anyone wanting to provide one or more of those objects or services was merely supposed to follow the appropriate interfaces and write implementations for them. Applications were written to the interfaces and thus were automatically decoupled from the implementations. As a result of these reusable interfaces, you could also potentially reuse the objects and services that implemented them, as well as the applications that consumed them.

Problem is, it never seemed to work out as easily as that. Most of the time, the interfaces people came up with were just too specific, and nobody could agree to apply them widely. Think of all the time people spent over the years in OMG, JSR, and W3C WS meetings trying to agree on just the infrastructure interfaces and not always succeeding. It’s therefore not surprising that there was never much success at defining broadly-accepted standard interfaces up at the application level; the scope is simply far too wide up there.

So, with technologies that promote interface variability, planned reuse is pretty hard. Consequently, serendipitous reuse, where services and facilities can be combined and reused beneficially in unforeseen ways, is virtually out of the question.

Stu Charlton’s blog was where I first saw those terms used, and I found them very enlightening. So did Bob Warfield.

One of the first things that attracted me to REST was the uniform interface constraint. Mark Baker first brought it to my attention nearly 8 years ago, and before I looked at it, I thought it was just a bad idea, like a totally generic doIt() interface, devoid of any meaningful semantics. But of course, there’s much more to it than that. The HTTP interface, for example, strikes a great balance that allows it to be efficiently reused across a very wide variety of applications. And when such a uniform interface is reused, the applications that use it stand a much better chance of being reusable themselves than if they were written against a non-uniform application-specific interface.

My latest Internet Computing column, entitled Serendipitous Reuse (and here’s the pdf if you prefer), explores how the uniform interface contributes to reuse of both the planned and serendipitous kinds.

Dilip Ranganathan pointed me to a long rant from Ganesh Prasad about using SOAP at Internet scale. I see that Stu Charlton already chimed in there with some good comments and analysis, but I think there’s still more to say.

Unless I’m missing something, Ganesh seems to be saying, “Hey, if we just stick SOAP directly onto TCP, we can scale beyond Web scale to Internet scale!” Oh, if it were only so easy. I would think that it’s fairly obvious that just because TCP scales well doesn’t mean that higher-level protocols sitting on top of it automatically scale to the same degree.

Why does the Web scale so well? Because of particular constraints deliberately imposed to induce specific architectural properties. The caching constraint contributes heavily to Web scalability, for example. Statelessness and the uniform interface also play a big role there. These constraints along with conditional GET allow messages to be significantly reduced in size or better yet, eliminated altogether. The resulting scalability impact is huge.

Ganesh talks about a lot of the things you’d have to add to the mix get a useful SOA ecosystem on top of SOAP/TCP, but nowhere does he talk about the specific architectural properties and constraints required to make it all scale. Without that, it just ain’t gonna happen. Furthermore, I don’t believe any system based either on interface specialization (i.e., the opposite of the uniform interface constraint) or on “processThis” can scale to Web scale. Interface specialization significantly increases coupling while reducing visibility and applicability, while “processThis” is so devoid of semantics that it offers nowhere to practically apply constraints like caching and statelessness that are so critical to scalability.

Don says he agrees with a lot of what James has to say about Stefan’s recaps of the QCon SOA Track, listed below:

• Dan’s talk
• Pete’s talk
• Sanjiva’s talk
• my talk

I too agree with many of James’s insights. If you don’t regularly read his blog, you should subscribe immediately. I especially like this quote:

When I consider SOA and REST today, I do not see two competing visions, I see an evolution that has brought the industry back to a core set of fundamental design principles that we seemed to have lost sight of for a while.

How very true. However, I disagree with just one small point: his critique of the part of my talk where I said SOA has no constraints (as Mark Baker has been pointing out for years now).

James says that SOA has constraints, it’s just they’re just not well-documented. I know exactly what he’s saying, but I have to stick with what I said. The only official definition of SOA that I know of is the OASIS SOA Reference Model, which mentions several desirable properties for SOA systems, but it documents no constraints for inducing them AFAICS. Later in my talk, as Stefan’s notes indicate, I did say that I was willing to concede that the OASIS SOA RM promotes the client-server constraint. However, I was being really, really generous, since all the specification really does is hint that SOA systems should be distributed, and “distributed” has a lot more meanings than just “client-server.”

Since there are no official standard SOA constraints, the only constraints you get are the ones that each vendor or supplier of SOA platforms and systems decides to give you. Naturally, each different solution in this space will differ in those constraints.

As the quote from James above implies, pitting SOA and REST against each other doesn’t make a lot of sense. The reason I went to the trouble of pointing out in my talk that SOA is missing critical architectural requirements like constraints was to help illustrate the significant differences between SOA and REST. Fundamentally, as I also said in my talk, SOA isn’t really about architecture in the way that REST is. Rather, it’s about IT culture, best practices, breaking down the enterprise organizational and political barriers that needlessly increase IT costs, and following good fundamental software engineering principles like reuse, minimizing coupling, and maximizing cohesion.