Difference between SOAP and REST web services in java

We have already seen SOAP web services and RESTful web services in detail before. In this post, we are going to see differences between SOAP and REST web services.

SOAP vs REST web services

Parameter	SOAP	REST
Acronym	SOAP stands for simple object access protocol	REST stands for REpresentational State Transfer
Protocol vs Architectural style	SOAP is a standard protocol to create web services	Rest is architectural style to create web services.
Contract	Client and Server are bind with WSDL contract	There is no contract between client and Server.
Format Support	SOAP supports only XML format	REST web services supports XML, json and plain text etc.
Maintainability	SOAP web services are hard to maintain as if we do any changes in WSDL , we need to create client stub again	REST web services are generally easy to maintain.
Service interfaces vs URI	SOAP uses Service interfaces to expose business logic	Rest uses URI to expose business logic
Security	SOAP has its own security : WS-security	Rest inherits its security from underlying transport layer.
Bandwidth	SOAP requires more bandwidth and resources as it uses XML messages to exchange information	REST requires less bandwith and resources. It can use JSON also.
Learning curve	SOAP web services are hard to learn as you need to understand WSDL , client stub	REST web services are easy to understand as you need to annotate plain java class with JAX-RS annotations to use various HTTP methods.

This is all about Difference between SOAP and REST web services in java. If you find more differences, please comment, so that I can include them in post.

RESTful web service tutorial

REST is an architectural style which was brought in by Roy Fielding in 2000 in his doctoral thesis.In the web services terms, REpresentational State Transfer (REST) is  a stateless client-server architecture in which the web services are viewed as resources and can be identified by their URIs. Web service clients that want to use these resources access via globally defined set of remote methods that describe the action to be performed on the resource.

It consists of two components REST server which provides access to the resources and a REST client which accesses and modify the REST resources.

In the REST architecture style, clients and servers exchange representations of resources by using a standardized interface and protocol.REST isn’t protocol specific, but when people talk about REST they usually mean REST over HTTP.
The response from server is considered as the representation of the resources. This representation can be generated from one resource or more number of resources.

REST allows that resources have different representations, e.g.xml, json etc. The rest client can ask for specific representation via the HTTP protocol.

HTTP methods :

RESTful web services use HTTP protocol methods for the operations they perform.Methods are:

• GET:It defines a reading access of the resource without side-effects.This operation is idempotent i.e.they can be applied multiple times without changing the result
• PUT :  It is generally used for updating resouce.It must also be idempotent.
• DELETE : It removes the resources. The operations are idempotent i.e. they can get repeated without leading to different results.
• POST :It is used for creating a new resource. It is not idempotent.

Idempotent means result of multiple successful request will not change state of resource after initial application

For example :

Delete is idempotent method because when you first time use delete, it will delete the resource (initial application) but after that, all other request will have no result because resource is already deleted.

Post is not idempotent method because when you use post to create resource , it will keep creating resource for each new request, so result of multiple successful request will not be same.

Features of RESTful web services:

Resource identification through URI:Resources are identified by their URIs (typically links on internet). So, a client can directly access a RESTful Web Services using the URIs of the resources (same as you put a website address in the browser’s address bar and get some representation as response).

Uniform interface: Resources are manipulated using a fixed set of four create, read, update, delete operations: PUT, GET, POST, and DELETE.

Client-Server: A clear separation concerns is the reason behind this constraint. Separating concerns between the Client and Server helps improve portability in the Client and Scalability of the server components.

Stateless: each request from client to server must contain all the information necessary to understand the request, and cannot take advantage of any stored context on the server.

Cache: to improve network efficiency responses must be capable of being labeled as cacheable or non-cacheable.

Named resources – the system is comprised of resources which are named using a URL.

Interconnected resource representations – the representations of the resources are interconnected using URLs, thereby enabling a client to progress from one state to another.

Layered components – intermediaries, such as proxy servers, cache servers, gateways, etc, can be inserted between clients and resources to support performance, security, etc.

Self-descriptive messages: Resources are decoupled from their representation so that their content can be accessed in a variety of formats, such as HTML, XML, plain text, PDF, JPEG, JSON, and others.

SOAP web service tutorial

Simple Object Access Protocol (SOAP) is a standard protocol specification for message exchange based on XML. Communication between the web service and client happens using XML messages.
A simple web service architecture have two components

• Client
• Service provider

So as in above diagram,how client will communicate to service provider.So in order to communicate client must know some information for e.g.

• Location of webservices server
• Functions available,signature and return types of function.
• Communication protocol
• Input output formats

Service provider will create a standard XML file which will have all above information.So If this file is given to client then client will be able to access web service. This XML file is called WSDL.

What is WSDL?

WSDL stands for Web Service Description Language. It is an XML file that describes
the technical details of how to implement a web service, more specifically the URI,
port, method names, arguments, and data types. Since WSDL is XML, it is both
human-readable and machine-consumable, which aids in the ability to call and bind to
services dynamically.using this WSDL file we can understand things like,

•     Port / Endpoint – URL of the web service
•     Input message format
•     Output message format
•     Security protocol that needs to be followed
•     Which protocol the web service uses

Ways to access web service:

There are two ways to access web service.

• If Service provider knows client:If service provider knows its client then it will provide its wsdl to client and client will be able to access web service.

• Service provider register its WSDL to UDDI and client can access it from UDDI:UDDI stands for Universal Description, Discovery and Integration.It is a directory service. Web services can register with a UDDI and make themselves available through it for discovery.So following steps are involved.
  1. Service provider registers with UDDI.
  2. Client searches for service in UDDI.
  3. UDDI returns all service providers offering that service.
  4. Client chooses service provider
  5. UDDI returns WSDL of chosen service provider.
  6. Using WSDL of service provider,client accesses web service.

What is SOAP?

SOAP is an acronym for Simple Object Access Protocol. It is an XML-based messaging protocol for exchanging information among computers. SOAP is an application of the XML specification.

Points to Note

• SOAP is a communication protocol designed to communicate via Internet.
• SOAP can extend HTTP for XML messaging.
• SOAP provides data transport for Web services.
• SOAP can exchange complete documents or call a remote procedure.
• SOAP can be used for broadcasting a message.
• SOAP is platform- and language-independent.
• SOAP is the XML way of defining what information is sent and how.
• SOAP enables client applications to easily connect to remote services and invoke remote methods.

Although SOAP can be used in a variety of messaging systems and can be delivered via a variety of transport protocols, the initial focus of SOAP is remote procedure calls transported via HTTP.

Other frameworks including CORBA, DCOM, and Java RMI provide similar functionality to SOAP, but SOAP messages are written entirely in XML and are therefore uniquely platform- and language-independent.

What is REST?

REST is called Representational State Transfer. It is a software architecture style. The World Wide Web (www) is the best example of REST.

1. Interfaces are limited to HTTP (REST is as good as stateless HTTP).

- HTTP GET is used for obtaining a representation of a resource.

- HTTP DELETE is used for removing representations of a resource.

- HTTP POST is used for updating or creating the representations of a resource.

- HTTP PUT is used for creating representations of a resource.

2. REST is used to describe interfaces that transmits domain-specific data over HTTP without an additional messaging layer such as SOAP or session tracking via HTTP cookies.

3.a. A resource is any item of interest. e.g. user. Clients may access this resource with this url "http://example.com/users/{user}" (one for each user).

3.b. A representation of the resource is returned. e.g. 001.html. The representation places the client application in a state. The client traverses further and another resource is accessed. The new representation places the client application in yet another state. Thus the client application state is transfered with each resource representation. Therefore Representational State Transfer.

4. REST lays emphasis on the diversity of resources - what we call nouns. The resources could be potentially very large.

5. RPC lays emphasis on the diversity of protocols and specialized operations - what we call verbs.

6. An RPC client application must know about an object's identity and data type to locate it and communicate with it.

7. A REST application provides addresses for every useful data object and uses those objects as the targets of operations.

8. SOAP and XML-RPC are both designed to operate from a single URI with methods being invoked from within the request payload.

9. REST uses HTTP as it was designed, if you want to get some data you use a HTTP GET request, if you want to delete a record from a database you use a HTTP DELETE request, etc.

10. RPC says, "define some methods that do something" whereas REST says, "define some resources and they will have these methods".

Advantages of REST

• It uses well documented, well established, well used technology and methodology.
• It's already here today; in fact it's been here for the last 12 years!
• Resource centric rather than method centric.
• Given a URI anyone already knows how to access it.
• It's not another protocol on top of another protocol on top of another protocol on top of...
• The response payload can be of any format (some may call this a disadvantage, however the Web copes with it, it's just a case of defining the application grammar).
• Uses the inherent HTTP security model, certain methods to certain URIs can easily be restricted by firewall configuration, unlike other XML over HTTP messaging formats.
• REST makes sense, use what we already have; it is the next logical extension of the web.

Views of a system

4 + 1 views of a System

The 4 + 1 notation represents four distinct views of a system and one overview of how everything fits together.

The four views are:

Design view (Logical):
1. The design view captures the classes, interfaces, and patterns that describe the representation of the problem domain and how the software will be built to address it.

2. The design view uses class, object, composite structure, activity and sequence diagrams to convey the design of the system. The design view doesn't address how the system will be implemented or executed.

3. It addresses end users, developers and represents the functional requirements and maps them onto classes in a platform independent manner.

Deployment view (physical view):
1. The deployment view captures how a system is configured, installed and executed.

2. It consists of component, deployment and interaction diagrams. The deployment view captures the physical layout.

3. It addresses system engineers and non-functional requirements.

Implementation view (development view):
1. The implementation view focuses on the configuration management of a system; what components depend on what, what source files implement what classes, etc.

2. It consists of component, interaction, statechart, composite structure diagrams.

3. Layered pattern could be used to describe the implementation view.

Process view:
1. The process view of a system is intended to capture concurrency, performance and scalability information. It consists of activity, interaction diagrams.

2. It addresses the concerns of system integrators.

The four distinct views of a system are brought together with the final view:

Use case view (scenarios) -
1. The use case view captures the functionality required by the end users.

2. The use case view is often broken down into collaborations that link a use case with one or more of the four basic views.

3. The use case view includes use case diagrams and typically uses several interaction diagrams to show use case details.

What is loose coupling?

The loose coupling concept has multiple dimensions. For instance -

1. Integration between two applications may be loosely coupled in time using message-oriented middleware - meaning the availability of one system does not affect the other.
2. Integration may be loosely coupled in format using middleware to perform data transformation - meaning differences in data models do not prevent integration.
3. The service interface is independent of the implementation - meaning applications can be built by composing one or more services without knowing the services' underlying implementation.