SOAP vs. REST

What is SOAP?

SOAP stands for Simple Object Access Protocol. It is a messaging protocol that uses structured XML-format messages to exchange information between applications.

There are two main rules for using SOAP, dictated by the World Wide Web Consortium (W3C):

1. All the information exchange must be in an XML format and must be used by both applications.
2. The XML must be structured in a very certain way, which consists of an envelope that contains an optional header and a message body:

                        <soap:Envelope>
                            <soap:Header>...</soap:Header>
                            <soap:Body>
                                ...
                            </soap:Body>
                        <soap:Envelope>
                    

• The envelope contains information about the encoding and attributes required for the message.
• The header might contain attributes about the way the message should be processed and authentication information, such as username and password.
• The body contains the actual request and response messages. It may also contain a “Fault” element that includes information about error handling.

The pros and cons of SOAP

SOAP makes use of inherent extensibility and logic features, as well as implementing its own security measure – WS-Security. This makes SOAP a good solution for large corporations.

However, the use the of tag heavy XML envelopes slows down the request and response processing time and consumes bandwidth, especially when there is a heavy traffic of requests. In addition, the rigid scheme of the protocol slows down adoption and implementation, as both client and server must use the SOAP message structure. 

What is REST?

REST stands for REpresentational State Transfer. It is an architecture style which is implemented while designing a web application.

There are five constrains that define a RESTful architecture:

1. Uniform interface – every element or piece of data can be a resource, that has its own uniform resource identifier (URI). There is no strict guideline for a resource can be. REST makes explicit use of HTTP methods to create, read, update or delete these resources, using their unique identifier.
2. Statelessness – the server does not maintain a record of the state of the system. Each request is independent of any previous requests and must contain all the data required for handling.
3. Caching – the data within the response must be labeled as either cacheable or non-cacheable and can be stored locally by the client.
4. Layering – REST enables HTTP intermediaries to exist between the client and the server, that can be used for message translation, caching, or serving as proxy servers or gateways.
5. Code-on-demand – This is optional. The response can include a script that runs on the client-side.

The pros and cons of REST

REST is an open architecture that enables any message format to be used. Its caching constraint improves performance by reducing the number of requests for duplicate resource. The statelessness and layering constraints improve performance and scalability since there every message is self-contained, and the layers enable to control the traffic of requests and responses between the client and the server.

However, REST doesn’t provide the same level of security a large corporation might need. In addition, REST’s statelessness constraint dictates that the request should include information that is possibly redundant. This might consume bandwidth and create latency in the delivery of messages.