SOAP, REST, Postmen and Telephones

Once upon a time, SOAP was Simple Object Access Protocol.




That is some 310 characters in simple enough message.
What we want to do is to execute a remote method such as:

Amount getAccountBalance (AccountNumber);

We also wish to ask a specific endpoint:
http://example.org/account for the answer.

The actual ask could be encapsulated in as few as 65 characters.

In this example, our question’s payload grows ~5 times. The reason is that we are not ASKING A QUESTION; we create an intermediate message that does it, including complete explanation of the intent. We than sent the message to the other side, that will do nothing upon receiving the message – there is no business meaning to receiving a message, yet. The receiver has to open the envelope, read the message and reconstruct sender’s intent. Only then can the receiver actually ANSWER the question – but it proceeds to put the ANSWER into yet another vanilla envelop and send it back to the original sender, continuing the cycle.

Consider following scenario: Jane wants to ask John “What time is it?”
A SOAP service could do something like this:

Figure 1 Wait a minute Mr. Postman!


This certainly works, but there is a significant overhead in this style of interaction. Think of all the logistic and recycling needs! Also, there are dangers lurking in the shadows: Ink may dry up. Letterhead paper may run out. Or we maybe out of stamps!

It works, but we could do better..

Imagine a phone conversation:

Figure 2 Mr. Marconi? Hello?











There is no reconstruction of sender’s intent needed, the receiver reacts directly to sender's QUESTION.

This is much like RESTful style

HTTP GET www.john.org/time
HTTP/1.1 OK 200
10 AM

~
The proposition of SOAP style messaging is that it can abstract communication details. SOAP message is a SOAP message is a SOAP message. A letter can travel all around the world. It used to be that letters were the only way how to communicate remotely.

But SOAP also abstracts the actual QUESTIONS. We exchange envelopes of “mysterious content” and reconstruct senders and receivers intent encapsulated within on each respective side. OVER AND OVER AGAIN.

The main benefit I see is that SOAP is transport agnostic. I am not tied to HTTP for my Web services. Is it worth the price? Is the cost benefit justifiable? I don’t think so. Especially when I introduce other WS-* concerns, which snowball INTO my SOAP message, I quickly come to a need for dedicated midle ware, effective compression and transformation mechanisms etc. I’ll take SIMPLICITY, instead.

In RESTful style, we can ask more direct questions. The question is expressed directly to the RESOURCE, not through auxiliary message. There’s little need to keep introducing additional, verbose, xml based mechanism “encapsulate” the QUESTION and make it generic “Message”. Understanding of a Resource IS generic already, just as Jane knows what time is, so she can ask the QUESTION about it.

WS - Reuse - Simplicity - Consistency

Reuse in Web Service world. I think about reuse from the perspective of two major architectural styles - Message based (SOAP) and RESTful. It seems to me that SOAP based architecture is poor fit when we aim for REUSE, from its very foundation.

Let's have a look at the building blocks of both styles (pic below), with a bit of a twist. Clearly, SOAP style ignores the full CRUD API of its most usual transport protocol - HTTP. Instead of using full set of HTTP API - GET, POST, PUT and DELETE, it uses POST only - just as transport gimmick.

There maybe some good reasons for this, but what it also inherently means is that this very CRUD capability of HTTP needs to be replicated on the service API - after all CRUD change is what we want to do with the service.
Each service now has to re-implement a definition of CRUD capability by itself! Just by definition of this information interchange, we mandate waste. We do not use what we have and invent something new for the same purpose.

Not only is this an replication and overhead on the service provider side, it also causes an overhead on service consumer side, where each consumer pretend they do not know what they want to do, must "learn" (i.e. discover) the capability set of each service, map it onto their original intent, exchange messages with the service provider and interpret the results. So we have reimplemented the same capability, just made it more complex.

Compare that with simplicity of RESTful approach. No auxiliary messages, no discovery of APIs, each service has the same set of capabilities - HTTP methods. These methods than "transfer" "service state representations" (an instance of resource) from consumer to provider. To know WHERE to transfer and to know WHAT is the relationship of resources - there are URIs, to know HOW to transfer- there're the methods of HTTP. To navigate and relate, there's hypertext. No fancy middle ware needed, short and sweet information exchange using the battle tested infrastructure of WWW.

Now that is some sweet REUSE - SIMPLICITY - CONSISTENCY!