A couple days ago I promised an article analyzing the SOAP approach to building a web service. Well here I am keeping those promises for you all. SOAP can be looked at as the tried and true method for developing a web service. It has been around much longer than REST and currently has a much larger user base. SOAP is another technical acronym meaning ‘Simple Object Access Protocol’. It was originally developed as a replacement for the popular XML-RPC which even I do not know much about (its that dated). Since I am much more versed in REST than SOAP I will give you a quick breakdown on how it differs from REST. If you want more information, post a comment and I will find the answer for you.

As stated in the REST article, REST requires the use of the HTTP protocol to communicate. This differs from SOAP which can be altered to communicate over any existing protocol that supports Unicode such as SMTP. Depending on who you talk to this can very useful or a violation of protocol definitions as SMTP was never meant to be used the way it is with SOAP. Another key difference is the treatment of the send/receive mechanics the two protocols use. SOAP uses formatted XML requests mirroring those of a command line which instructs the server how to treat the object. REST on the other hand treats everything the same and ignores these sort of commands. This is why the two protocols are commonly said to be “verb” or “noun” centric. SOAP needs parameters which tell it the action it needs to perform and how to do it. While REST just needs to know the subject (or resource) and it will return the data to you in a standard format.

Since the data SOAP returns can be manipulated through the use of these commands it adds a layer of complexity in the returned XML. This complexity can be a benefit if your needs require you do perform specialized operations, but in most cases it becomes a hassle. This is the benefit of REST, you know what you are getting as long as you requested the correct resource.

When designing an API for your web service, keep in mind the level of specialized operations your service needs. If you foresee the use of such operations you may want to take the SOAP route, otherwise save yourself some headaches and utilize REST.