Will Enterprise Architects Get Any REST in 2008? - ' 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."