I find myself becoming more and more a REST believer.  Maybe I just want to be different, to buck the trend, to dismiss the hype.  It seems to me that SOAP web services get too much hype because, as they say, when all you have is a hammer, everything looks like a nail.  For many people in IT, SOAP is the solution for just about everything.

I can think of many situations where REST is much more appropriate that SOAP.  For example, there are many binary document formats, and SOAP is just not good for handling binary data.  How about an image database (JPEG or TIFF files), or a voice messaging system (WAVE files), or even a repository of office documents (Word and Excel files)?  Yes, I know about DIME, but it seems like a kludge compared to a simple HTTP solution.

With SOAP, things get complicated when you start to design a really good API.  There are so many layers.  Consider the issue of error handling.  At each layer, there is the possibility of an error.  So, error handling must go something like this:

1. Was the client-server communication link successfully created and used?  (Check for socket errors.)
2. Was the HTTP request accepted by the server?  (Check the HTTP response code.)
3. Did the SOAP command itself succeed?  (Check for a SOAP fault.)

With REST, error handling stops at step 2.  In fact, with REST, the errors in step 2 and step 3 are actually combined, because errors at the application layer are reported as HTTP errors.  In SOAP, HTTP is not the application layer; it's another layer of communication that can get in the way.

12:06:58 AM