REST
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.

e.g.

http://MyTESTTWL.DOMAIN/api/session.

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.

Caching:

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.

Framework:

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.

e.g.

getUser(User);

Web Services:

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

Example:

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.
WS-ReliableMessaging:

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

WS-AtomicTransaction:

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.

Weight:

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.