SOAP vs REST

Posted: December 6, 2010 in Dotnet basics

SOAP vs REST

SOAP – Simple Object Access Protocol
REST – REpresentation State Transfer

SOAP is a protocol for sending/receiving data over HTTP as XML.
A typical WebService will be a few methods an WSDL that describes how to call it. There’s no real convention for how these should be structured, so you

always need lots of API documentation.
Typically this will be something like (for .net):
•Http POST to mysite.com/products.asmx/ListAllProducts – returns XML list of products
•Http POST to mysite.com/products.asmx/GetProduct – returns XML for product based on SOAP XML in the posted content
•Http POST to mysite.com/products.asmx/UpdateProduct – changes product based on SOAP XML in the posted content

REST is more of a convention for structuring all of your methods:
•Http GET from mysite.com/products – returns XML or JSON listing all products
•Http GET from mysite.com/products/14 – returns XML or JSON for product 14
•Http POST to mysite.com/products/14 – changes product 14 to what you post in the HTML form.
So REST works more like you’d expect browser URLs to. In that way it’s more natural and as a convention is much easier to understand. All REST APIs work in

a similar way, so you don’t spend as long learning the quirks of each system.
REST goes further, so ideally the following would work:
•Http DELETE to mysite.com/products/14 – removes product 14
•Http PUT to mysite.com/products – adds a new product
Unfortunately the majority of browsers don’t implement these HTTP verbs, so you have to rely on GET and POST for now

—————————————————————————————————————–

SOAP – SOAP has become the standard for exchanging XML-based messages. SOAP was also designed from the ground up to be extensible, so that other standards

could be integrated into it–and there have been many, often collectively referred to as WS-*: WS-Addressing, WS-Policy, WS-Security, WS-Federation, WS-

ReliableMessaging, WS-Coordination, WS-AtomicTransaction, WS-RemotePortlets, and the list goes on.

The basic structure of SOAP is like any other message format (including HTML itself): header and body. In SOAP 1.2 this would look something like
<!–

<env:Envelope xmlns:env=”http://www.w3.org/2003/05/soap-envelope“>
<env:Header>
Header information here
</env:Header>
<env:Body>
Body or “Payload” here, a Fault if error happened
</env:Body>
</env:Envelope>

–>

Note that the <Header> element is optional here, but the <Body> is mandatory

The SOAP Header Element The optional SOAP Header element contains application-specific information (like authentication, payment, etc) about the SOAP

message. If the Header element is present, it must be the first child element of the Envelope element.

The mustUnderstand Attribute The SOAP mustUnderstand attribute can be used to indicate whether a header entry is mandatory or optional for the recipient to

process.  If you add mustUnderstand=”1″ to a child element of the Header element it indicates that the receiver processing the Header must recognize the

element. If the receiver does not recognize the element it will fail when processing the Header.

<!–
<?xml version=”1.0″?>
<soap:Envelope
xmlns:soap=”http://www.w3.org/2001/12/soap-envelope
soap:encodingStyle=”http://www.w3.org/2001/12/soap-encoding“>

<soap:Header>
<m:Trans xmlns:m=”http://www.w3schools.com/transaction/
soap:mustUnderstand=”1″>234
</m:Trans>
</soap:Header>


</soap:Envelope>
–>

The SOAP <Body>
The SOAP body contains the “payload” of the message, which is defined by the WSDL’s <Message> part. If there is an error that needs to be transmitted back to

the sender, a single <Fault> element is used as a child of the <Body>.

The SOAP <Fault>
The <Fault> is the standard element for error handling. When present, it is the only child element of the SOAP <Body>. The structure of a fault looks like:
<!–
<env:Fault xmlns:m=”http://www.example.org/timeouts“>
<env:Code>
<env:Value>env:Sender</env:Value>
<env:Subcode>
<env:Value>m:MessageTimeout</env:Value>
</env:Subcode>
</env:Code>
<env:Reason>
<env:Text xml:lang=”en”>Sender Timeout</env:Text>
</env:Reason>
<env:Detail>
<m:MaxTime>P5M</m:MaxTime>
</env:Detail>
</env:Fault>
–>
A Simple SOAP Example
Putting it all together, below is an example of a simple request-response in SOAP for a stock quote. Here the transport binding is HTTP.

The request:

GET /StockPrice HTTP/1.1
Host: example.org
Content-Type: application/soap+xml; charset=utf-8
Content-Length: nnn

<?xml version=”1.0″?>
<env:Envelope xmlns:env=”http://www.w3.org/2003/05/soap-envelope
xmlns:s=”http://www.example.org/stock-service“>
<env:Body>
<s:GetStockQuote>
<s:TickerSymbol>IBM</s:TickerSymbol>
</s:GetStockQuote>
</env:Body>
</env:Envelope>

The response:

HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset=utf-8
Content-Length: nnn

<?xml version=”1.0″?>
<env:Envelope xmlns:env=”http://www.w3.org/2003/05/soap-envelope
xmlns:s=”http://www.example.org/stock-service“>
<env:Body>
<s:GetStockQuoteResponse>
<s:StockPrice>45.25</s:StockPrice>
</s:GetStockQuoteResponse>
</env:Body>
</env:Envelope>
——————————————————————————————————————-

REST – The emergence of the RESTful style of web services was a reaction to the more heavy-weight SOAP-based standards. In RESTful web services, the emphasis

is on simple point-to-point communication over HTTP using plain old XML (POX).

Representative State Transfer (REST). REST is an architectural style that can be summed up as four verbs (GET, POST, PUT, and DELETE from HTTP 1.1).

HTTP     CRUD Equivalent
==============================
GET      read
POST     create,update,delete
PUT      create,update
DELETE   delete

Re-writing the stock quote service above as a RESTful web service provides a nice illustration of the differences between SOAP and REST web services.

The request:

GET /StockPrice/IBM HTTP/1.1
Host: example.org
Accept: text/xml
Accept-Charset: utf-8
The response:
HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Content-Length: nnn

The response :

<?xml version=”1.0″?>
<s:Quote xmlns:s=”http://example.org/stock-service“>
<s:TickerSymbol>IBM</s:TickerSymbol>
<s:StockPrice>45.25</s:StockPrice>
</s:Quote>
To summarize their strengths and weaknesses:

*** SOAP ***

Pros:
Langauge, platform, and transport agnostic
Designed to handle distributed computing environments
Is the prevailing standard for web services, and hence has better support from other standards (WSDL, WS-*) and  tooling from vendors
Built-in error handling (faults)
Extensibility

Cons:
Conceptually more difficult, more “heavy-weight” than REST
More verbose
Harder to develop, requires tools

*** REST ***

Pros:

Language and platform agnostic
Much simpler to develop than SOAP
Small learning curve, less reliance on tools
Concise, no need for additional messaging layer
Closer in design and philosophy to the Web

Cons:

Assumes a point-to-point communication model–not usable for distributed computing environment where message may  go through one or more intermediaries.
Lack of standards support for security, policy, reliable messaging, etc., so services that have more sophisticated  requirements are harder to develop

(“roll your own”)
Tied to the HTTP transport model

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s