A Web service is a method of communications between two electronic devices over the World Wide Web.
It is also defined as a software system designed to support interoperable machine-to-machine interaction over a network.
In simple words, “Web services are developed to use by other software applications”
Web services communicate via either SOAP or REST messages.
REST stands for REpresentational State Transfer. It is a term coined by Roy Fielding in his Ph.D. dissertation
It is an architecture style for designing networked applications which typycally runs runs over HTTP.
REST is an architecture and not a “standard”. There is no w3c recommendation for REST. It is concept for better web and widely accepted.
RESTful applications use HTTP requests to post data (create and/or update), read data (e.g., make queries), and delete data. Thus, REST uses HTTP for all four CRUD (Create/Read/Update/Delete) operations.
It expects client to have knowlege of what to send and what to expect in response. It is focused on accessing named resources through a single consistent interface.
- It is simple
- It is lightweight and faster
- runs over HTTP
- Response can be returned in “XML/JSON” format
Like Web Services, REST offers no built-in security features, encryption, session management, QoS guarantees, etc. But also as with Web Services, these can be added by building on top of HTTP:
For security, username/password tokens are often used.
For encryption, REST can be used on top of HTTPS (secure sockets).
The Web is comprised of resources. A resource is any item of interest. For example, A software company may have many products. Clients may access particular product with this URL:
SOAP, originally defined as Simple Object Access Protocol. It is a protocol specification for exchanging structured information in the implementation of Web Services in computer networks.
SOAP is an XML based protocol for accessing Web Services.
It is designed to handle distributed computing environments.
It is well defined mechanism for describing the interface e.g. WSDL+XSD, WS-Policy. As it is standardised it becomes complex t
It provides a large number of supporting standards for security, reliability, transactions.
Here content of the message decides what to perform and reponse (payload) must comply with SOAP schema.
It defines 3 fundamental properties:
- What service does: Operations provides
- How service is accessed: Data format and protocol details
- Where a service is located: Adress (URL) details
Sample SOAP request structure:
In the example below, a GetStockPrice request is sent to a server. The request has a StockName parameter, and a Price parameter that will be returned in the response. The namespace for the function is defined in “http://www.example.org/stock”.
Sample SOAP response structure:
Here are few reasons for which you may want to use SOAP:
- Platform and laguage independent
- Follows W3C standard
WSDL (Web services description language) is a W3C standard based on xml and is used to describe web services.
It supports SSL (just like REST). It also provides a standard implementation of data integrity and data privacy. Being “Enterprise” it’s more secure.
- Atomic Transactions
It supports ACID Transactions (WS- Atomic Transactions) so it can provide two phase commit over distributed transactional resources.
- Reliable Messaging
It has successful/retry logic built in and provides end-to-end reliability even through SOAP intermediaries
Whenever complex or likely to change API getting developed then SOAP could be a good choice.