SOAP brings its own protocol and focuses on exposing pieces of application logic (not data) as services.

Addresses :

Method

Transport Protocol Supported:

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 :

SOAP is strongly function-driven

URL Structure / Metadata:

URL structure depends on functionality.

Operation / Function Dependability:

For every operation need to write separate function / Method.

Data formats Supported:

SOAP supports XML by default.

Caching:

SOAP based reads cannot be cached.

Recommended For:

Secure applications, for example - Banking.

Supports WSDL:

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

HTTP 1.1 verbs:

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

Error Handling:

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:

Strongly typed messaging framework

Defines Contract:

The WSDL is often explained as a contract between the provider and the consumer of the service.

Operations vs Accessing Named Resources:

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:

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

Example:

Google authentication

Distributed system:

Works well in distributed enterprise environments.

WS* standards:

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

Data formats Supported:

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 :