After innumerous, heated discussions about REST versus SOAP at my workplace, I finally decided to dedicate some time to writing something about it. I began by trying to understand the reason for such passion from both parties of this discussion, and came to the conclusion that we approached the subject from different views; the developer view, and the architect view. Allow me to explain my reasoning.
Developers, often, become acquainted with a technology and end up wanting to use it everywhere as if it were the best thing since sliced bread. Architects, on the other end, have to ponder upon all aspects of the technology, understand its essence, and decide whether or not it is applicable to the task at hand. I would say, pushing it a little to the extreme, that developers love REST while architects have a tendency to not like it so much. To an architect, REST seems like anarchy, as if, “I don´t want any standards that I can´t understand, I want to do things my way!”. The discussion of REST services versus SOAP services falls in this category, and I will try to contribute to clarifying when to use one or the other.
I am not going to give yet another definition of REST; there are plenty on the internet to suit everyone’s taste. Nonetheless, I will have to list its main characteristics:
- Use of the HTTP protocol and its verbs (e.g., GET, PUT, POST or DELETE)
- Address specific resources through URIs (Universal Resource Identifiers)
More important than the definition of REST and its characteristics (which are very important and should be well understood) is the approach to take.
Imagine a banking scenario with a database of customer accounts. To give customers access to their accounts, the IT department decided to expose Web Services but doesn’t know yet which is the best solution; REST or SOAP.
The first step is to identify the resources. In this particular case, the resources are customer bank accounts.
The second step is to establish an addressing convention that, on one end, uniquely identifies each of the unique accounts, and on the other, all the accounts as a whole.
So far so good, the REST approach seems to apply without breaking its definition. The next step is to expose the functionality to the customers through HTTP verbs. Let´s start with the GetAccountBalance operation.
This operation maps perfectly to the GET HTTP verb as suggested above. Same thing happens to the DepositAccount operation through the use of the PUT HTTP verb, and the CloseAccount operation with the DELETE HTTP verb. The troublesome part comes with the AccountTransfer operation. First of all, this operation does not map directly to an HTTP verb, second, it addresses two different resources, the uri for the withdrawal account and the uri for the deposit account. To accomplish this with the REST approach, I would have to consider, for instance, the POST HTTP verb, and pass in the HTTP payload the identifier of one of the resources (withdrawal or deposit account). This is a violation of the REST principles; first standard HTTP verbs do not map to this kind of operations, and second, we cannot uniquely identify all the resources we are trying to address through the HTTP URI field.
Following a SOAP approach, the AccountTransfer operation could be implemented in the following manner:
While REST is a good approach for some situations (typically CRUD scenarios), other applications need a more flexible approach such as the use of SOAP. REST is more oriented for storage based applications such as Amazon´s S3, Windows Azure Storage Services, VMWare vCloud, and globally most Cloud Computing Services out there. SOAP, on the other hand, is more oriented for operations where logic is exposed instead of resources. Typically, SOAP is used in SOA implementations (as opposed to WOA with REST) where there is greater need for standards such as WS* (security, interoperability, discoverability, reliable messaging, transactions, etc.). In terms of security, and opposed to the WS*, which have a very well defined and standard security model, REST does not have any predefined security methods (often relying solely on HTTPS), leaving it to the developers to define their own.