Rest and Soap Based Webservices

Web Services

A Web Service is can be defined by following ways:

• Is a client server application or application component for communication.
• Method of communication between two devices over network.
• Is a software system for interoperable machine to machine communication.
• Is a collection of standards or protocols for exchanging information between two devices or application.

Let's understand it by the figure given below:

As you can see in the figure, java, .net or PHP applications can communicate with other applications through web service over the network. For example, java application can interact with Java, .Net and PHP applications. So web service is a language independent way of communication.

  

Service Oriented Architecture (SOA)

Service Oriented Architecture or SOA is a design pattern. It is designed to provide services to other applications through protocol. It is a concept only and not tied to any programming language or platform.

Web services are a technology of SOA most likely.

 

Service

A service is well-defined, self-contained function that represents unit of functionality. A service can exchange information from another service. It is not dependent on the state of another service.

 

Service Connections

The figure given below illustrates the service oriented architecture. Service consumer sends service request to the service provider and service provider sends the service response to the service consumer. The service connection is understandable to both service consumer and service provider.

Types of Web Services

   There are mainly two types of web services.

·         SOAP web services.

·         RESTful web services.

RESTful Services are appropriate in this scenario:

·         If you have limited bandwidth

·         If your operations are stateless: No information is preserved from one invocation to the next one, and each request is treated independently.

·         If your clients require caching.

While SOAP is the way to go when:

      ·         If you require asynchronous processing

      ·         If you need formal contract/Interfaces

      ·         In your service operations are stateful: For example, you store information/data on a request    and use that stored data on the next one.

      ·         The main advantage of SOAP is that it provides a mechanism for services to describe themselves to clients, and to advertise their existence.

      ·         In general, when you're publishing an API to the outside world that is either complex or likely to change, SOAP will be more useful.

      ·         If your application needs a guaranteed level of reliability and security then SOAP offers             additional standards to ensure this type of operation.

Pros & Cons of SOAP 
    

  Pros:

           ·         Language, 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 & 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--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

---