Tuesday, July 20, 2010

REST and SOAP

As we all know that this is more of a Architectural decision, there are few things that I would like to keep handy while deciding among two. These should help me taking the right design decision for right type of end point.

Here I am trying to Simplify the WCF stuff. There are 2 Major type of services and clients that you would need to know for majority of the Services consumers.

- For using WS* and all the high end transactional features of WCF, USE SOAP

Easy to consume – sometimes
Rigid – type checking, adheres to a contract

- For light weight, simple XML, if you can take care of security user REST

Lightweight – not a lot of extra xml markup
Human Readable Results

Examples -

REST - Twitter, Yahoo’s web services , Flickr, del.icio.us, pubsub, bloglines, technorati best is? – Craigslist !

SOAP - Google is consistent in implementing their web services using SOAP, with the exception of Blogger, which uses XML-RPC.

Both? -  eBay and Amazon

Now REST vs SOAP - 

1 API Flexibility & Simplicity – Rest is simple and SOAP is not

2. Rest APIs are lightweight – less bandwidth – SOAP requires Bunch of XML wrapped around where as for 4 digit stock price we dont need this overhead :)

3. Security- Posts using SOAP across organizational boundaries are safe, However RESTs Get are can always be consider safe because technically it can not modify an data. SOAP typically uses the POST to communicate with service. analyzing HTTP command in firewall is simple and REST can benefit out of it. However, to do this with SOAP you have to open the SOAP packet which makes it resource consuming. There is no way to know just by looking at the request if it wants to get or delete etc.

On the other hand, think about sending SSN as parameter in Query string. there rest goes down. Again Large data  becomes difficult

4. Authentication and Authorization – For SOAP its all upto developer. For REST – through use of certificates, common identity mgmt services like LDAP developers can make use of this

Clients – easier to create a Client for SOAPs that REST but this depends on how the framework is. Testing and troubleshooting is very easy with HTTP API than SOAP as building request is far simpler.

Caching – easer with REST as it is consumed with GET, intermediate proxies can cache the responses easily. 

Server Side complexity – SOAP is easier to code on server side, nearly all high level langs and framework makes it easy to create a  SOAP endpoints. With REST you are exposing objects methods as HTTP API and requires serialization of output to XML. Also you need to map the URI path to specific handlers.