Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Scribd
Upload
178 views

Understanding SOAP and REST Basics

SOAP and REST are protocols for accessing web services. SOAP relies on XML messaging and has built-in error handling, while REST uses simple URLs and standard HTTP methods. Both have advantages - SOAP is standardized and supports distributed systems, while REST has a smaller learning curve and more efficient message formats. The choice depends on factors like required features, architecture, and development effort.

Uploaded by

dhamikd
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
178 views

Understanding SOAP and REST Basics

SOAP and REST are protocols for accessing web services. SOAP relies on XML messaging and has built-in error handling, while REST uses simple URLs and standard HTTP methods. Both have advantages - SOAP is standardized and supports distributed systems, while REST has a smaller learning curve and more efficient message formats. The choice depends on factors like required features, architecture, and development effort.

Uploaded by

dhamikd
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 4

Understanding SOAP and REST Basics

Simple Object Access Protocol (SOAP) and REpresentational State Transfer (REST) are two
answers to the same question: how to access Web services. The choice initially may seem
easy, but at times it can be surprisingly difficult.

its important to clarify that both SOAP and REST are protocols: a set of rules for requesting
information from a server using a specific technique.

A Quick Overview of SOAP


SOAP relies exclusively on XML to provide messaging services.
The point is that SOAP is highly extensible, but you only use the pieces you need for a
particular task. For example, when using a public Web service thats freely available to
everyone, you really dont have much need for WS-Security.
The XML used to make requests and receive responses in SOAP can become
extremely complex.
One of the most important SOAP features is built-in error handling. If theres a problem
with your request, the response contains error information that you can use to fix the
problem. Given that you might not own the Web service, this particular feature is
extremely important; otherwise you would be left guessing as to why things didnt work.
The error reporting even provides standardized codes so that its possible to automate
some error handling tasks in your code.
An interesting SOAP feature is that you dont necessarily have to use it with the
HyperText Transfer Protocol (HTTP) transport.

A Quick Overview of REST


Many developers found SOAP cumbersome and hard to use. For example, working with
SOAP in JavaScript means writing a ton of code to perform extremely simple tasks
because you must create the required XML structure absolutely every time.
REST provides a lighter weight alternative. Instead of using XML to make a request,
REST relies on a simple URL in many cases. In some situations you must provide
additional information in special ways, but most Web services using REST rely
exclusively on obtaining the needed information using the URL approach. REST can
use four different HTTP 1.1 verbs (GET, POST, PUT, and DELETE) to perform tasks.
Unlike SOAP, REST doesnt have to use XML to provide the response. You can find
REST-based Web services that output the data in Command Separated Value (CSV),
JavaScript Object Notation (JSON) and Really Simple Syndication (RSS). The point is
that you can obtain the output you need in a form thats easy to parse within the
language you need for your application.

SOAP is definitely the heavyweight choice for Web service access. It provides the
following advantages when compared to REST:

Language, platform, and transport independent (REST requires use of HTTP)

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

point communication)
Standardized

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

Built-in error handling

Automation when used with certain language products

REST is easier to use for the most part and is more flexible. It has the following
advantages when compared to SOAP:

No expensive tools require to interact with the Web service

Smaller learning curve

Efficient (SOAP uses XML for all messages, REST can use smaller message
formats)
Fast (no extensive processing required)
Closer to other Web technologies in design philosophy

Some may be wrong in table below:

REST

SOAP

Assumes a point-to-point communication


modelnot usable for distributed computing
environment where message may go through
one or more intermediaries

Designed to handle distributed


computing environments

Minimal tooling/middleware is necessary. Only


HTTP support is required

Requires significant
tooling/middleware support

URL typically references the resource being


accessed/deleted/updated

The content of the message


typically decides the operation
e.g. doc-literal services

Not reliable HTTP DELETE can return OK


status even if a resource is not deleted

Reliable

Formal description standards not in


widespread use. WSDL 1.2, WADL are
candidates.

Well defined mechanism for


describing the interface e.g.
WSDL+XSD, WS-Policy

Better suited for point-to-point or where the


intermediary does not play a significant role

Well suited for intermediated


services

No constraints on the payload

Payload must comply with the


SOAP schema

Only the most well established standards


apply e.g. HTTP, SSL. No established
standards for other aspects. DELETE and PUT
methods often disabled by firewalls, leads to
security complexity.

A large number of supporting


standards for security,
reliability, transactions.

Built-in error handling (faults)

No error handling

Tied to the HTTP transport model

Both SMTP and HTTP are valid


application layer protocols
used asTransport for SOAP

Less verbose

More verbose

You might also like