Demystifying SOAP / REST and Understanding the Differences
Part I : Understanding basic concepts
SOAP -Simple Object Access Protocol
- SOAP is a method of transferring messages, or small amounts of information, over the internet.
- SOAP builds an XML protocol on top of HTTP.
- SOAP describes functions, and types of data.
- SOAP is a successor of XML-RPC and is very similar, but describes a standard way to communicate.
- Several programming languages have native support for SOAP, you typically feed it a web service URL and you can call its web service functions without the need of specific code.
- Binary data that is sent must be encoded first into a format such as base64 encoded.
REST -Representational State Transfer
- REST is an architecture.
- REST is very lightweight.
- Typically uses normal HTTP methods instead of a big XML format describing everything.
- REST is a very simple in that it uses HTTP GET, POST and PUT methods to update resources on the server.
- REST typically is best used with Resource Oriented Architecture (ROA). In this mode of thinking everything is a resource, and you would operate on these resources.
- As long as your programming language has an HTTP library, and most do, you can consume a REST HTTP protocol very easily.
- Binary data or binary resources can simply be delivered upon their request.
Part II : Application scenarios
When to use REST?
- Limited bandwidth and resources. Remember the return structure is really in any format (developer defined). Plus, any browser can be used because the REST approach uses the standard GET, PUT, POST, and DELETE verbs. Again, remember that REST can also use the XMLHttpRequest object that most modern browsers support today, which adds an extra bonus of AJAX.
- Totally stateless operations. If an operation needs to be continued, then REST is not the best approach and SOAP may fit it better. However, if you need stateless CRUD (Create, Read, Update, and Delete) operations, then REST is it.
- Caching situations. If the information can be cached because of the totally stateless operation of the REST approach, this is perfect.That covers a lot of solutions in the above three.
When to use SOAP ?
- Asynchronous processing and invocation. If your application needs a guaranteed level of reliability and security then SOAP 1.2 offers additional standards to ensure this type of operation. Things like WSRM — WS-Reliable Messaging.
- Formal contracts. If both sides (provider and consumer) have to agree on the exchange format then SOAP 1.2 gives the rigid specifications for this type of interaction.
- Stateful operations. If the application needs contextual information and conversational state management then SOAP 1.2 has the additional specification in the WS* structure to support those things (Security, Transactions, Coordination, etc). Comparatively, the REST approach would make the developers build this custom plumbing.