REST

SOAP

Stands for:

Representational State Transfer Protocol Simple Object Access Protocol

What is it:

RESTs sweet spot is when you are exposing a public API over the internet to handle CRUD operations on data. SOAP brings its own protocol and focuses on exposing pieces of application logic (not data) as services.

Addresses :

Resource Method

Transport Protocol Supported:

Only supports HTTP.

REST requires use of HTTP.

SOAP can be sent over almost any protocol such as HTTP, SMTP, TCP, or JMS.

SOAP is Language, platform, and transport independent.

Data vs Function Driven :

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

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

URL structure depends on functionality.

Operation / Function Dependability:

Operation depends on verbs.

e.g.

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

Delete -Logout

Post(username, password) - login

For every operation need to write separate function / Method.

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.

SOAP supports XML by default.

Caching:

REST reads can be cached. SOAP based reads cannot be cached.

Recommended For:

For Public facing APIs. Secure applications, for example - Banking.

Supports WSDL:

No, WSDL Support. Web Services Description Language (WSDL) - SOAP depends to a large degree on the language you use

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.

SOAP also defines a binding to the HTTP protocol. When binding to HTTP, all SOAP requests are sent through GET, POST request.

Error Handling:

No error information is provided by response.

SOAP features is built-in error handling.

If there’s a problem with your request, the response contains error information that you can use to fix the problem.

Framework:

Open ended / Flexible framework. Strongly typed messaging framework.

Defines Contract:

No, WSDL / Contract is defined. The WSDL is often explained as a contract between the provider and the consumer of the service.

Operations vs Accessing Named Resources:

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

e.g.

getUser(User);

SOAP exposes operations

e.g.

switchCategory(User, OldCategory, NewCategory)

Every operation the service provides is explicitly defined, along with the XML structure of the request and response for that operation. Each input/output parameter is similarly defined and bound to a type: for example an integer, a string, or some other complex object.

Web Services:

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

SOAP has very little if anything to do with the Web.

Example:

Flicker, Twitter API Google authentication

Distributed system:

REST assumes direct point-to-point communication. Works well in distributed enterprise environments.

WS* standards:

WS*Standards are not supported.

Provides significant pre-build extensibility in the form of the WS* standards :

WS-Addressing, WS-Policy, WS-Security, WS-Federation, WS-ReliableMessaging, WS-Coordination, WS-AtomicTransaction, and WS-RemotePortlets.

Security:

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

SOAP is more secured that REST services.

It also provides a standard implementation of data integrity and data privacy.

WS-ReliableMessaging:

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

SOAP has successful/retry logic built in and provides end-to-end reliability even through SOAP intermediaries.

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.

Need ACID Transactions over a service, you’re going to need SOAP.

Weight:

REST is lightweight than SOAP.

SOAP is heavyweight than REST.

Performance and Scalability:

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

Fast (no extensive processing required) and supports JSON.

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. REST is easier to use for the most part and is more flexible, efficient.