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.