SOAP and REST

Overview#

SOAP stands for Simple Object Access Protocol.

REST stands for Representational State Transfer.

Both are web standards used for the communication between web services.

SOAP#

SOAP Introduction#

SOAP(using WSDL) is a heavy-weight XML standard that is centered around document passing. The advantage with this is that your requests and responses can be very well structured, and can even use a DTD. The downside is it is XML, and is very verbose. However, this is good if two parties need to have a strict contract(say for inter-bank communication). SOAP also lets you layer things like WS-Security on your documents. SOAP is generally transport-agnostic, meaning you don't necessarily need to use HTTP.

SOAP: Simple Object Access Protocol Specification:

<soap:Envelope>
<soap:header/>
<soap:Body>
<creditcard>
.....
</creditcard>
</soap:Body>
</soap:Envelope>

The SOAP header is used to send meta-information such as usernameToken, username, password etc.

WSDL The contract in XML format. Tells what the WS provides and how it provides and how you can consume it.

SOAP (Pros)#

  • Platform independent
    • HTTP: Transport independent
    • XML: Data independent
  • Application Tailoring / Customization
  • Legacy applications are great

SOAP (Cons)#

  • Ambiguous Web Services Standards
  • Performance Impact due to Serialization & De-Serialization

When to use SOAP#

  • When a formal contract is required to describe the interface. WSDL describes what information WS provides
  • Non-Functional Requirements
    • Security
    • Transaction Management
  • Reliable Asynchronous Processing between producer & consumer

REST#

REST Introduction#

REST is very lightweight, and relies upon the HTTP standard to do it's work. It is great to get a useful web service up and running quickly. If you don't need a strict API definition, this is the way to go. Most web services fall into this category. You can version your API so that updates to the API do not break it for people using old versions(as long as they specify a version). REST essentially requires HTTP, and is format-agnostic(meaning you can use XML, JSON, HTML, whatever).

  • REST: REpresentational State Transfer
  • Utilises HTTP methods such as POST, GET, PUT, DELETE
  • Uses URI to perform CRUD operations
  • Allows multiple file formats for exchange (MIME types) such as XML, JSON, TXT etc.
  • REST is stateless: State can be maintained on the client side rather than server side. -> Allows scalabity as the applications can be deployed on several servers as user base grows
  • Single HTTP Interface

REST (Pros)#

  • Provides Add, Update, Delete, Read operations with 1 single interface.
  • Stateless
  • Scability (due to the stateless property) -> allows us to cache too

REST (Cons)#

When to use REST services#

  • Well defined contract exists (mutual understanding between consumer and service provider) since there is an absence of a WSDL file
  • Multiple Data Formats
  • Bandwidth & Memory (SOAP is more heaviweight whereas REST is light)
  • Stateless (Your app is stateless if it survives a restart)
  • Caching
  • Existing logic can be exposed easily