REST here, REST there, REST everywhere. Where are the REST principles though?

It’s been a long time since I wrote about my views on a WS or SOA related topic. The “Simple JAVA and .NET SOA interoperability” article at InfoQ made me want to write something again. I can’t believe someone can write so many inaccuracies in a single article. I blame the use of the term ‘REST’ which today is a buzzword rather than the name of a set of architectural principles which do not relate to a specific technology.

First of all, .NET and Java do not force a particular interpretation of WSDL; that’s what tooling built on top of these technologies does. Also, there is this organization called “WS Interoperability Organization” which has produced profiles for a number of WS standards (WSDL is one of them). If our favorite tooling does not comply to those profiles, then we can change it. There are so many tools out there that will help us happily with our interoperability needs. Also, popular service providers on the Web (e.g. Amazon, Google, Microsoft) are offering access to their exposed functionality through SOAP-based messaging with the interactions (messages and message exchange patterns) described in WSDL. Their use of WSDL is pretty standard as far as I am concerned and trouble-free with most tooling.

The fact that the paper describes a method of interpreting SOAP messages as the representation of RPC calls is the core problem. SOAP is a message format with well-defined message processing semantics. If I want to build distributed applications where documents flow from node to node rather than making use of RPC calls, I can very easily do so. Many tools support one-way messaging and also direct access to the SOAP message structure. This article suggests that by moving from SOAP to XML over HTTP will solve all interoperability problems. How is what the authors propose any different from encapsulating those exact same documents in a soap:Body?

I particularly liked this:

“We did not use a name/value pair for the XML: we simply used the entire POST body, which is a little outside of the HTTP specification. It is a matter of preference though – as long as its the same on client and server.”

An excellent piece of advice to building interoperable systems. We shouldn’t care about a specification as long as the client and the server agree on an interpretation. Perhaps Amazon should tell all the millions of its clients out there to interpret the HTTP specification the way Amazon understands it.

I am not going to touch the random discussion on schemas and extensibility, but such matters are addressed by XML Namespaces and open content.

The good advices keeps coming. Since Web Services and XML don’t go well together (yeah, SOAP is not XML), we should convert our XML document to strings and pass them as arguments to ‘methods’!

Here’s another gem:

“WSDL only flags incompatibilities at runtime, when recovery is very hard”.

What about when a service is deployed on the Internet? Are we going to be certain that we have covered all possible cases with our unit tests? How are we going to inform our consumers about our requirements/characteristics of our service?

This imperative unit testing approach just isn’t as scalable as the declarative mechanism that a contract provides. Declaratively capturing requirements and capabilities for services and enforcing them at runtime with the assistance of tooling is a necessity for services (as opposed to

server) deployments.

And we reach the end with a great conclusion: the paper admits that the safety semantics of GET are lost with the use of POST. So, we should do XML over HTTP using POST (because we don’t like SOAP), we should not use GET, and still the subtitle of the article suggests that this is a discussion on REST! :-)))

 

XML over HTTP is a great way to integrate systems; the Web and all of the services offered on the Web make use of it. REST captured a set of architectural principles as an afterthought by concentrating on the concept of a resource, a distributed hypermedia application, uniform interfaces, and state transfers between representations. However, many of the applications we see on the Web make use of the uniform semantics of the HTTP verbs (mainly GET) while often ignoring the architectural principles of REST.

Also, as I have said a number of times, one could build RESTfull applications using any technology!