Will Enterprise Architects Get Any REST in 2008?

By David F. Carr  |  Posted 2007-12-20

Will this be the year that the Web development architecture known as REST invades the enterprise, derailing or fundamentally altering the orthodox approach to web services and service oriented architecture (SOA) that's been built up over the past several years?

There are plenty of REST enthusiasts who think it ought to happen – and many who would say it's inevitable – but even if there won't be an overnight revolution, the time may be ripe for enterprise folks to evaluate REST as an alternative or at least to considering how they might apply some of the principles behind it to streamlining their ongoing SOA efforts.

Representational State Transfer (REST) is a style of application architecture derived from the way the web works, and REST advocates argue that mimicking web-like patterns of interaction is a way of simplifying the development of network applications. Although it's not really a distributed computing protocol akin to SOAP, the XML-based message format at the heart of most enterprise web services architectures, REST is often positioned as an alternative to SOAP – and the and the whole sprawling family of XML standards that have grown up around it.

"For simple applications, you don't need all that SOAP baggage," says Joe Morrison, a senior consultant at Lab49, which works primarily with financial services firms. "The REST approach is about modeling service oriented architectures the way the web is built, and trying to make distributed applications look as much as possible like large-scale web sites."

The financial services industry is investing heavily in SOA, Morrison says, and at least in the short run those efforts are not likely to shift from SOAP to REST. "In my mind, it's a little like the Mac versus PC debate, where SOAP is like the PC – maybe not the most elegant, but practically it meets a lot of enterprise requirements."

Still, Morrison expects more enterprises to start experimenting with REST and embracing some of the thinking behind it in how they implement web services, regardless of technology.

Gartner analyst Nick Gall agrees, saying that REST is attracting attention from "a select group of enterprise architects." In other words, it's really only on the radar for a relatively small group of enterprise technologists, he says, but they tend to be leading-edge thinkers.

So far, REST has been most influential among the new businesses that have grown up with the Web and who do most of their business over the Internet and among developers who have embraced REST-friendly frameworks such as Ruby on Rails.

When Roy T. Fielding described REST in a doctoral thesis published in 2000, he wasn't so much inventing something as formalizing principles derived from years of work on web standards. Fielding was the principal author of the HTTP 1.1 specification and a prime contributor to other web standards, including the Uniform Resource Identifier (URI) addressing scheme, and one of the founders of the Apache web server open source project. He now serves as Chief Scientist at Day Software, a content management system vendor.

Next page: Part two

When you use the web, your browser issues HTTP GET commands every time you enter a new address or click on a link and HTTP POST commands for data entry forms. REST suggests that these standard operations and a couple of others (such as PUT and DELETE) are also a natural way of designing machine-to-machine communications. For example, a program can explore the programming interface of a remote service with a series of GET commands that bring back links to other resources.

Where SOAP is a specific XML protocol, REST is an architectural style – a set of rules for designing networked application. Applications can be described as more or less "RESTful" depending on how closely they adhere to those principles, but there's no official standard to implement, other than the basic protocols of the Web. That's one of the attractions for web-centric businesses because it means REST applications can run on the same caching, load balancing, and security infrastructure as other web applications, without requiring additional middleware.

Fielding finds it annoying that SOAP and related standards became synonymous with web services, given that their workings aren't particularly web-like. "I never considered them web services – at best, they're XML services," he says.

SOAP, which was originally known as the Simple Object Access Protocol, became less "simple" as the result of efforts to create sophisticated enterprise services on top of it. SOAP started out as a way of using XML and invoke the functions of remote software objects or components over the web's Hypertext Transfer Protocol (HTTP) and followed in the tradition of other types of remote procedure call, distributed object computing, and message oriented middleware systems. The SOAP specification itself defines the format of an XML "envelope" that wraps around the actual message or "payload" and specifies its destination. Since it was introduced in the late 1990s, with the backing of both Microsoft and the vendors of Java-based middleware, SOAP has been at the center of the marketing of the concept of web services and, more recently, SOA.

The promise of these technologies has always been that they would bring new levels of reuse, flexibility, and agility to enterprise systems. But even though there are many success stories to be told, Gartner's Gall says enterprise architects are starting to feel some jealously for what's happening outside the corporate firewall. "These guys are looking over their shoulders at the true web – at what's going on with Google and Amazon and mashups – and saying, 'Hey, wait a minute, how come we're not getting that level of flexibility out this stuff you sold us called 'web services,' " he says.

Clients who are disappointed by the payoff from their SOA efforts have often created too much unnecessary complexity, Gall suggests. One of the reason that web-oriented architectures like REST have an advantage is that they're simpler and therefore easier to reuse and mash up, he says.

Even if it's not practical for an enterprise to make a wholesale shift from SOAP to REST, the organization can use the contrasting example of public web services as an impetus for simplification. For example, SOAP services are typically described with WSDL (Web Services Description Language) files. Often, by asking how many WSDL files the client has created, Gall says he discovers the enterprise has created hundreds of "one-off" WSDL files. Often, one reason the underlying services aren't particularly reusable is that they lack common data definitions. One way of changing that is to combine SOA efforts with master data management and making sure services, for example, use only master lookup keys to identify customers.

Next page: Part 3

Lab 49's Morrison makes a similar point about the lessons enterprise architects can take from REST. "The REST people have one really compelling idea, which is that every time you create a URI for something, you add value to the entire web," he says, and the same is true for the web of resources within an enterprise. In order to maximize the value of a computing resource, REST developers also tend to put more care into naming that resource. For example, instead of giving the service a name associated with a specific database – when the database architecture might change over time, rendering that name obsolete – a good REST design would peg the name to the type of information the service provides.

But there's no reason that same care can't be applied to SOAP services design, Morrison says. "Anytime someone wants to put out a new service, I try to ask them, 'Are you prepared to support this for 5 years? Would that change the way you would make this service work?' Because it's really a mistake to create services too promiscuously."

Eventually, he hopes to see convergence. "You could take the REST idea and incorporate that into SOAP, and I think that will probably happen," Morrison says.

While some concepts may be shared, however, the two approaches are probably too different to be truly merged. "REST and HTTP have a completely different design center from distributed enterprise transactions," says Larry Cable, vice president and corporate architect at BEA Systems. "They're headed off in different directions."

"One decision made very early in the design of the SOAP protocol was not to use URIs for anything other than naming the service endpoint," Cable says, so one URI can be used to invoke multiple services, based on the addressing contained in the SOAP envelope. So that's a direct conflict with the principles of REST.

BEA supports SOAP web services with its WebLogic middleware products and has also started to tout REST support. However, there's actually very little BEA needs to do to support REST, Cable says. "One of the reasons the RESTful style of programming is so attractive is that it doesn't require you to use a very complex technology stack to transfer data. You don't necessarily need an interface description language, for example."

Where the REST style starts to break down, Cable argues, is in scenarios that require the enterprise qualities like security and transaction integrity.

But Fielding says framing the question as simplicity versus sophistication is a false choice. "In reality, it requires the most sophistication to create a simple system, whereas it's trivial to create a system that nobody understands," he says. "Really what REST does is constrain the application developer or the designer of these systems into following a pattern that makes every interface simple. If you do that, later on, you can recombine these interfaces and simple and interesting ways."

While he doesn't claim REST is the right choice for every application – he's willing to rule out nuclear power plant control systems, for example – Fielding says "it just happens to be applicable to about 90-plus percent of the applications people build."