REST vs SOAP

For some reason people who work in technology seem to have well defined opinions about matters and will often go to great lengths to defend those opinions. Think about the unix vi editor (I dislike), windows vs unix, windows vs apple. These topics will often lead to flame wars. Today I'm going to weigh in on web service transports and hope I don't light up a wildfire.

Early Binding vs Late Binding

I'm a supporter of the SOAP protocol for most cases unless the service is to be consumed by a javascript application. I've been thinking about why it is that I have this preference and I think I know exactly why. It comes down to early (or design time) binding of an external component vs late (or runtime) binding. This concept has been around since the early days of computer science, the idea being that a sub component can declare ahead of time what kind of operation signatures it supports so that these can be confirmed by the compiler. If a piece of code which has been bound at compile time fails at run time then we immediately know there is a conflict in versions. A similar concept is found in strongly typed languages. I can think of a few examples of this:

• java interfaces
• C/C++ header files
• WSDL - web service definition language

The bad part of using SOAP is that it requires additional overhead, but in simple cases this is little more that a message envelope.

The other side of the argument is run time binding where we find out about the operation signatures when the code is actually executed. Now this isn't as bad as one thinks because the component owner will always provide details about the shape of the data and what is expected so the consumer that write appropriate code. The bad part of this is that the service provider can change anything at any time without notifying the consumers, resulting in an error when the consumer attempts to invoke an operation. There is a similar concept in weakly typed languages:

• javascript
• visual basic
• assembly language

How to Choose?

The short answer is that this whole argument is moot if the software is well designed and written. All the valuable business logic should reside in java bean POJOs and then combined with a runtime container such as an enterprise service bus (ESB) or a service component architecture (SCA). The container manages exposing the POJO business logic using any number of transport protocols and can be configured at time of deployment. If an ESB or SCA is not available, then a similar result can be attained by coding a thin delegate using JAX-RS or JAX-WS.

Why do I prefer early binding? I don't like doing emergency production troubleshooting and with early binding I can eliminate one more point of failure.