Stands for: Representational State Transfer Protocol
What is it: RESTs sweet spot is when you are exposing a public API over the internet to handle CRUD operations on data.
Addresses : Resource

Transport Protocol Supported:

Only supports HTTP.

REST requires use of HTTP.

Data vs Function Driven :

REST is very data-driven, compared to SOAP, which is strongly function-driven.

URL Structure / Metadata:

In the REST paradigm, metadata is structured hierarchically and represented in the URI; this takes the place of the noun.

Operation / Function Dependability:

Operation depends on verbs.



Delete -Logout

Post(username, password) - login

Data formats Supported:

REST supports both XML, Command Separated Value (CSV), JavaScript Object Notation (JSON) and Really Simple Syndication (RSS) format.

JSON usually is a better fit for data and parses much faster.

REST allows better support for browser clients due to its support for JSON.


REST reads can be cached.

Recommended For:

For Public facing APIs.
Supports WSDL: No, WSDL Support.

HTTP 1.1 verbs:

The HTTP standard offers several verbs representing operations or actions you can perform on the data, most commonly: GET, POST, PUT, and DELETE.

REST can use four different HTTP 1.1 verbs (GET, POST, PUT, and DELETE) to perform tasks.

Error Handling: No error information is provided by response.


Open ended / Flexible framework.

Defines Contract:

No, WSDL / Contract is defined.

Operations vs Accessing Named Resources:

REST is focused on accessing named resources through a single consistent interface.



Web Services:

REST provides true “Web services” based on URIs and HTTP.


Flicker, Twitter API

Distributed system:

REST assumes direct point-to-point communication.

WS* standards:

WS*Standards are not supported.

Security: REST is not secure as SOAP. Primarily used for public facing apps.

Rest doesn’t have a standard messaging system and expects clients to deal with communication failures by retrying.


While REST supports transactions, it isn’t as comprehensive and isn’t ACID compliant.

REST is limited by HTTP itself which can’t provide two-phase commit across distributed transactional resources, but SOAP can. Internet apps generally don’t need this level of transactional reliability, enterprise apps sometimes do.


REST is lightweight than SOAP.

Performance and Scalability:

REST has better performance and scalability - as it supports JSON.

Fast (no extensive processing required) and supports JSON.

Easier to Use / Flexible and Efficient:

REST is easier to use for the most part and is more flexible, efficient.