SOAP VS REST Web Service

Web services can be developed using soap standard or REST standard.

Lets compare features provided by both standards with advantages and disadvantages.

SOAP – Simple Object Access Protocol

1. Exposes Operations that implement/represent logic
2. Provides loose coupling for integrating diverse systems
3. Designed for distributed systems.
4. Designed to be extensible – WS-*
5. Standard error messaging – SOAP faults with standard code/ subcode for error types
6. Aligns with enterprise application needs and goals.

• Supports other transport protocols than HTTP – SMTP, JMS
• Supports enterprise security with WS-Security.
• Supports language neutrality
• Supports ACID, Atomic transactions with WS-AT
• Support Reliable Messaging with WS-RM
• Easy governance with strong typing.
• Broad development tool support

REST

– Good for Web service

– Exposes RESOURCES which represent data

– Uses HTTP verbs (GET / POST / PUT / DELETE)

– Emphasis on simple point – to – point communication over HTTP

– Supports multiple data formats

– Emphasizes stateless communication

SOAP

– Good for Enterprise services

– Exposes OPERATIONS which represent LOGIC

– Uses HTTP POST

– Emphasis on loosely coupled distributed messaging.

– Supports only XML and attachments

– Supports stateless and stateful / conversational  operations

– Supports asynchronous messaging

– String Typing

Why Rest is better than SOAP:

– REST can be consumed by any client, even a web browser with Ajax and javascript

– REST is light weight. 1 – Rest doesn’t require XML parsing.   2 – Rest consumes less bandwidth – doesn’t require a SOAP header for every message

– Can learn to use REST very easily.It’s just nouns and verbs

Why SOAP is better than REST:

– Building a client for REST can be challenging and difficult and building client for SOAP will be easy

– I can easily generate client-side artifacts from a WSDL

– I don’t want to write raw http calls

– I don’t want to look at the http response code for success/failure

– REST only supports HTTP/HTTPS

– HTTP is synchronous and in order to scale I need to be able to have asynchronous messaging.

– REST is not secure

– Parameters are part of URL

– No support for acquiring token

– RESTful services have no contract

– Have a WADL that specifies URL’s but not schema for object definition