REST vs SOAP Webservices

After long time I am updating my blog since, I was very busy with my new project. Today I got some free time so thought I will update my blog with technology which I am using in my project. this time I am working on RESTful webservices ...ummm I know what next is coming in your mind..... what is RESTFul webservice and how its different from the the SOAP right ??? so here we go......

REST - stands for "Representational State Transfer", this basically means that each unique URL is a representation of some object. You can get the contents of that object using an HTTP GET, to delete it, you then might use a POST, PUT, or DELETE to modify the object (in practice most of the services use a POST for this).

SOAP - stands for "Simple Object Access Protocol" was designed to be a platform and language-neutral alternative to previous middleware techologies like CORBA and DCOM

Pros and cons of 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

Pros and cons of 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
• Generaly 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.
• Services that have more sophisticated requirements are harder to develop ("roll your own") Tied to the HTTP transport model