I’ve never used Simple Object Access Protocol (SOAP), because, since I’ve been a developer, I’ve always been involved in projects using Representative State Transfer (REST) services. Turns out, this wasn’t as simple of a question as I’d hoped. Also, it seems that it’s not an old protocol that nobody should use. It actually has plenty of good uses and a bunch of solid tools too.
- Supports multiple data formats, but usually XML-based messaging is used for strict schema design.
- The protocol has a bit of overhead for hand shaking (even if the Message Transmission Optimization Mechanism reduces the message sizes significantly.)
- Can be implemented over any transport layer (HTTP, SMTP, JMS, etc)
- Requires Web Services Description Language (WSDL), which can be used in proxies/caches. This defines interfaces of services and must be shared with whomever might be accessing your application
- Reliable – Retries are handled for you as part of the framework overhead
- All parts of the communication can be encrypted (even parameters)
- Strongly typed
- Extra security can be built in (WS-Security)
- Atomic operations can be built in. More than just transactions.
- Methodology: Exposes operations that can be done
- The core APIs on the JVM is JAX-WS
- Popular Java implementations include AXIS, CXF, and Spring-WS
- Supports multiple data formats – The most popular is JSON, but it also supports many other known types. With JSON, it tends to allow for human readable results.
- Considered to be a more lightweight solution – especially on the front end. Easy to build, no toolkits required. Though, it is still easier to access with libraries.
- Implemented directly on top of HTTP
- Emphasis on stateless communication – with the exception of POST/PATCH HTTP operations. All others are idempotent (can be repeated without repercussions – for example, if you are cacheing responses).
- Proxies/Caches need a custom solution
- Not strongly typed.
- Supports transactions, but not atomic operations
- Not reliable – retries have to be handled by application
- Methodology: Exposes resources, which represent data, and actions that can be done upon them
- The core APIs on the JVM is JAX-RS
- Popular Java implementations include CXF, Jersey, RESTEasy, and Spring-MVC.
So, looking at these, your architectural decisions should be based on the strengths of each protocol. Actually, you don’t even need to use just one, you could use both. In summary:
REST = good for Web services, limited bandwidth/resources, and combining content from many different sources in a web browser
SOAP = good for Enterprise services with an abundance of processing power – includes high reliability, transactions, security built in, asynchronous processing, and contract first development. Also, the strict schema makes is very good for passing around a lot of data.
99% of the time, I’m going to suggest REST as a protocol, especially since most of my work is web facing products only. However, now that I know a bit more about SOAP and how servers can use them for communications, I know what to do during the other 1% of the time.
Further reading material:
Makeup of SOAP – a comparison