RESTful VS SOAP

RESTful Web Service :

• It Does not maintains the state ie stateless webservice
• Its having in built cache mechanism to improve the performance while doing retrieve operation
• Its supports only HTTP/HTTPS Protocols
• Its supports Json and XML data formats , most prefer data transformation is Json 
• Its does not have any in built security mechanism 
• It does not supports the distributed transaction 
• It does not have any interface contract between provider and consumers instead only mutual understanding 
• Implementation is bit easy compared to SOAP
• Based on the JAX-RS Specification 
• Does not supports any Async calls 
• We can add/remove the consumer on fly since there is no contract between them
• Fast time to market compared to SOAP
• Its supports all the browser
• Its supports Http basic authenticaion for security 
• It perform the CRUD Operation only not for business logic
• Build in error handling with Http Status code 

SOAP Web Service 

•  Its stateful and stateless  Web service 
•  It has standard interface contract is called WSDL between provider and consumer
• It requires less plumping code compared to REST like transaction /security and etc
• Its support various protocols and also supports Async (JAX-WS) 
• Little heavier than RESTful and also performance issue is there compared to REST
• Less supports for light weight client like mobile client 
• There is no build in error handling support .
• Provides the Pre Build Extension with WS-*
• Its supports only XML
• We can't extend the implementation with out client knowledge unless we need implement the version
• It does not support any default cache mechanism . 
•  any machine to machine communication with Business process,security and Integrity 
• Mainly for distributed environment 

Choose SOAP or RESTful 

•  if you have predefine the consumer with agreed the Request and Response then move into SOAP ie  Standardize the IC between them
• Payload is heavy and requires build in Transaction /Security then move into SOAP
• if we need to support more protocols other than HTTP then move into SOAP 
• if you have more time and there is no major constraint in Performance then move into SOAP
• if there is no requirement to support the thin client along with performance issue then move into SOAP
• if the Webservice have more logic then CRUD operation then move into SOAP
• if we need to maintains the states between the call like on line shopping stuff then move into SOAP

Versioning in SOAP WS:


Since we made some changes in existing services with out impacting the consumer then we need to implement the versioning concept in any context , it may be services/component/plug in and etc.
SOAP WS handles the versioning in different ways . Implement Versioning in SOAP WS following strategy.

In SOA world (loosely coupled Architecture) ,Whenever we made a changes in the existing service , we can't expect the consumer to adopt those changes in Immediately  .It will be   very long  process to adopt . Some of the consumers are not ready to adopt those changes since those changes irrelevant to them . In this scenario application teams handle /implement the versioning in their existing services

Application Team responsible to implement the followings

1) Identify the changes either Minor /Major
2) Apply the proper patterns to implement the versioning
3) Review with industry practices and guidelines

Identify the Changes ;

Changes in the service may be addition of parameter in existing operation or adding the new operation or remove the existing operation or change the existing operation or adding the optional or mandatory parameters or any validation logic in the existing services , it may be break the existing consumers.

Application or Service Context , We can categorized into Major and Minor release based on the changes in the existing services.

If those changes break the existing consumers means those changes are treat as Major Release and if the changes are backward compatible then changes are Minor Changes .

Service Versioning come into the Picture only when it does not support backward compatible ie it will break the existing consumer due to the changes in existing one.

Standard for Version Number :


Implement the minor release in the following ways

1) Fix the Bug or any Performance enhancement , In this scenario WSDL does not changes . We make the Version number 1.0X

2) Adding the parameter or operation , WSDL needs to updates . We will make the version number 1.Y0

In Major release , Of course WSDL might change and also impact the existing the consumer. Now we need to plan carefully to implement those changes with impacting the existing consumer ie We update the version of WSDL with those changes with out breaking or with out adopting the existing consumer into new services. System should have some intelligent to adopt those cases.We have several patterns to implement the version in major release

1) Consumer Binding Pattern

2) Layer indirection Pattern

3) Adaptor Pattern

Due to complexity we have Mediation between the service , ESB is acting as Mediator to perform /implement the Version in SOAP WS.

Versioning in RESTful WebService :

Restful Web Service always invoke through URI ie Service Endpoint and there is no Contract agreement between the consumer and provider/

We can implement the Version in the following ways

1) Put the version no in the URL directly

Ex: http://<>/v1.0/<>

2) Pass the version number as the parameter in the URL

Ex: http://<>/<>?version =<>

3) Version Free URL

if there is no version in the URL then it will take /redirect to the latest Endpoint

4) Version number is Http Header


6) What is distributed transaction/2PC?

Distributed transaction is deal with more than one Database always . We need to perform the commit or rollback in more than one Database rather than single data base. Its mainly used in Distributed env.

2PC , two phase commit only in distributed transaction env. It has two phases 1) Commit Request Phase and Commit Phase.