The REST of the SOAP

For a good while now, I have been following the debates and developments around web services and the technological and architectonal standards around “web services”, and generally been struggling to understand what it has been all about, and to find out how we from an eGov position should look at things.

The Interoperability Frameworks from UK, Australia and NZ are onto something here:

Clearly defined policies and specifications for interoperability and information management are also key to staying connected to the outside world and aligned to the global information revolution. The e-Government Interoperability Framework (e-GIF) provides these. It is a fundamental Framework Policy for the e-Government strategy.
UK e-Government Interoperability Framework Version 4

e-GIF contains “the high level policy statements, management, implementation and compliance regimes” as well as “the technical policies and table of specifications, and a glossary and abbreviations list” for “the areas of interconnectivity, data integration, content management and information access via multiple channels”. In one word, this all comes down to XML, we are told.

Over a rather short time, the UK e-GIF has evolved through four versions. For the first three versions, it all looked like the project was to “XMLify” government. In April 2002, we saw e-GIF4, in which another (or, the real?) bomb is dropped:

Future WEB based service delivery is to be based on SOAP, UDDI and WSDL.

SOCITM’s comments on this point are worth quoting:

“These standards represent a step-change in introducing interoperability across Government. Before a mandate is introduced, guidance and toolkits must be made available to enable local strategies to be built and appraised.
While XML and SOAP are now the de facto standard, UDDI and WSDL are still emerging. Consequently a mandate should not be applied until these standards are established and mainstream.”

Indeed, I must agree with these comments. The UK e-GIF is an example of SOAP purism, if we follow eclectic’s definitions:

• REST Purist — Web services should be implemented using REST principles, according to the letter of the HTTP specifications. No other way is acceptable
• REST Realist — SOAP adds too much overhead, I prefer plain XML over HTTP, but aren’t too worried if I breach the specs occasionally. I need this to work now, but don’t see a need for more tools.
• SOAP Realist — I’m only really interested in the HTTP binding. SOAP makes my life easier because I can hide all the protocol ugliness behind the toolset. SOAP works for me, why shouldn’t I use it?
• SOAP Purist — SOAP is the only way to implement Web Services. The HTTP binding isn’t worth arguing about, as we’re going to bind to all kinds of other protocols as well. We need to to move on and deal with issues like orchestration, etc, etc.

In other words, if you thought the “battle” was between J2EE vs .NET, you thought wrong. The real battle is between purists and realists of both “sides”, SOAP vs REST.

And the REST is …

As Roy Fielding, the coiner of REST, put it:

REST is an architecture that separates server implementation from the client’s perception of resources, scales well with large numbers of clients, enables transfer of data in streams of unlimited size and type, supports intermediaries (proxies and gateways) as data transformation and caching components, and concentrates the application state within the user agent components.

Hmmm. So, what does that actually mean? According to the Rest FAQ, it means:

REST stands for REpresentational State Transfer. It is an attempt to describe the undocumented architectural design principles behind the Web.

Tricky definition, huh? Theory is practice, or, practice is theory. Or? RestArchitecturalStyle:

In a nutshell, REST defines identifiable resources, and methods for accessing and manipulating the state of those resources. As implemented on the World Wide Web, URIs identify the resources, and HTTP is the protocol by which resources are accessed. REST argues that HTTP itself — its minimal method set and semantics, and the ability to extend this method set as required — is sufficiently general to model any application domain; i.e., traditional OOP modeling of application objects with type-specific interfaces is unnecessary and replaced by modeling things as hierarchical families of abstract resources with a common interface and semantics defined by HTTP itself.

So, what is not REST? According to the RESTwiki contributors, the most important contrast with the REST architectural model is the Remote Procedure Call (or RPC) model, which “attempts” to take the local programming model of a function call and make it work across the network. SOAP is an example of the RPC model, of course. RESTwiki concludes:

The success of REST and the “failure” […] of previous attempts at RPC architectures such as DCOM, CORBA and RMI suggests that REST has superior characteristics of scalability and mass adoption, largely because of the low coordination costs.

State of Utah CIO, Philip Windley, takes a RESTian stance when he proposes the 12 principles for enabling web services. I can subscribe to almost all the principles, and I will try and use them in the Danish and the European e-GIFs.

Then Sam Ruby comes along and suggest that it is really not REST vs SOAP, it is REST + SOAP! Now I’m officially confused.