While the end goal is the same, REST and SOAP cannot be directly compared as REST is a set of guidelines that developers may choose to implement differently from project to project while SOAP is a well defined and standardized protocol for data exchange.



REpresentational State Transfer (REST) is a software architecture that was designed to operate over a world-wide network. Some of the core architecture principles are:

  • Layered abstraction between a resource (thing that manages objects) and object (e.g., database, file, etc.)
  • Lightweight (“loose”) coupling between the client and the server, addressing over the network through URIs
  • Easy to understand resource representation

The layered abstraction allows for the object implementation to be hidden from the requesting entity. This means that the underlying implementation can change on the resource side without impacting any other endpoint. Abstraction is a common software practice and REST takes abstraction to be at the application layer.

Clients (or user agents) are decoupled from the server as much as possible. This means that neither end point needs to have a tight coupling on implementation or interface. Moreover, addressing is done through a Uniform Resource Identifier (URL is an example of a URI) which allows for flexible identification of endpoints.

Working with a resource is easy to understand as it is in plain text for requests and responses.

How is REST used

A web service that follows REST practices has a “RESTful” interface. Web resources are made accessible through the URI. This mean that HTTP GET/PUT/POST/DELETE operations are valid on these resources. Data is exchanged either using JSON, HTML, or XML.

Considerations for REST


  1. Freedom to implement as needed
  2. Easier to implement because of flexibility (lack of explicit protocol implementation)
  3. Entities are accessible through URIs and interaction is with those entities directly
  4. HTTP allows for cached results which could be used to speedup response times


  1. Integration with other apps requires work as there is no defined standard
  2. Only used over HTTP
  3. No explicit security protocol or considerations
  4. Stateless


SOAP used to stand for Simple Object Access Protocol but that name was abandoned prior to the 1.2 release. SOAP is a message protocol meaning it defines the rules, syntax, semantics and synchronization for communication. SOAP consists of a prescribed SOAP-envelope which defines the information as a SOAP message. Inside the SOAP message can be a SOAP-header and will contain a SOAP-body. The SOAP-body defines the call and response information.

A RESTful interface can use SOAP. But it doesn’t make sense to say SOAP uses REST; SOAP is a protocol that can be used in a REST architecture. See the table in [4] for a great breakdown between SOAP and REST.

How is SOAP used

SOAP is used over application-layer protocols such as SMTP, HTTP, HTTPS. It only uses XML as the data format. SOAP has extensions for expansion including WS-Security. Endpoints that communicate via SOAP exchange Web Service Description Language (WSDL) files which describe the endpoint resources and operations.

Considerations for SOAP


  1. Standardized message format lends itself to reusable development, testing and debugging practices
  2. Expandable to include security practices
  3. Expandable to be stateful


  1. XML is beefy and thus the message exchange between endpoints has a longer latency
  2. When the resource changes, a new WSDL file needs to be provided to 3rd parties to integrate
  3. Service interfaces are used to access entities and interactions go through a middle-layer



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s