What is web services?
AÂ web serviceÂ is a piece of software that makes itself available over the internet and uses a standardized XML messaging system. XML is used to encode all communications to aÂ web service. For example, a client invokes aÂ web serviceÂ by sending an XML message, then waits for the corresponding XML response.
There are mainly two types of web services.
- SOAP web services.
- RESTful web services.
Components of Web Services
- SOAP (Simple Object Access Protocol)
- UDDI (Universal Description, Discovery and Integration)
- WSDL (Web Services Description Language)
Soap web services: – SOAP is XML based protocol. It is platform and language independent. By using SOAP, you will be able to interact with other applications designed in different programming languages.
Rest web services: – REST stands for Representational State Transfer, which is an architectural style for networked hypermedia applications, it is primarily used to buildÂ Web servicesÂ that are lightweight, maintainable, and scalable. A service based on REST is called a RESTful service.
Difference between SOAP and REST
|SOAP stands for Simple Object Access Protocol.||REST stands for Representational State Transfer.|
|SOAP is a XML based messaging protocol.||REST is an architectural style.|
|SOAPÂ permits XMLÂ data format only.||RESTÂ permits differentÂ data format such as Plain text, HTML, XML, JSON etc.|
|SOAPÂ defines standardsÂ to be strictly followed.||REST does not define too much standards like SOAP.|
|JAX-WSÂ is the java API for SOAP web services.||JAX-RSÂ is the java API for RESTful web services.|
|SOAP is distributed computing style.||REST is web style (web is also a distributed computing model).|
REST Web Service
REST stands for Representational State Transfer. REST was a term coined by Roy Fielding.
REST is not dependent on any protocol, but almost every RESTful service uses HTTP as its underlying protocol.
Using HTTP Methods for RESTful Services
Features of a RESTful Services: – A Restful web service should have following features.
- Uniform interface
- Links between resources
â€œThe focus of a RESTful service is on resources and how to provide access to these resources. A resource can easily be thought of as an object as inÂ OOP. A resource can consist of other resources. While designing a system, the first thing to do is identify the resources and determine how they are related to each other. This is similar to the first step of designing a database: Identify entities and relationsâ€.
In Rest we can use any format for representing our resources, as Rest does not put a restriction on the format of representation.
We can use either JSON format or XML format to represent our resource.
If you are building Web services that will be used by Web pages for AJAX calls, then JSON is a good choice. XML can be used to represent more complex resources.
JSON representation of a resource
XML representation of a resource
Note:-â€œThe representation should be capable of linking resources to each other. This can be done by placing the URI or unique ID of the related resource in a representationâ€.
â€œThe client and service talk to each other via messages. Clients send requests to the server, and the server replies with a response. Apart from the actual data, these messages also contain some metadata about the messageâ€.
An HTTP request has the format shown in Figure 1:
Figure 1: HTTP request format.
â€œ<VERB>Â is one of the HTTP methods likeÂ GET,Â PUT,Â POST,Â DELETE,Â OPTIONS, etc.
<URI>Â is the URI of the resource on which the operation is going to be performed
<HTTP Version>Â is the version of HTTP, generallyÂ “HTTP v1.1″Â .
<Request Header>Â contains the metadata as a collection of key-value pairs of headers and their values. These settings contain information about the message and its sender like client type, the formats client supports, format type of the message body, cache settings for the response, and a lot more information.
<Request Body>Â is the actual message content. In a RESTful service, that’s where the representations of resources sit in a message.
There are no tags or markups to denote the beginning or end of a section in an HTML messageâ€.
Example:- A sample POST request
You can see theÂ
POSTÂ command, which is followed by the URI and the HTTP version. This request also contains some request headers.Â
HostÂ is the address of the server.Â
Content-Type tells about the type of contents in the message body.
Example:- A sample GET request
There is no message body in this request. TheÂ
AcceptÂ header tells the server about the various presentation formats this client supports. A server, if it supports more than one representation format, it can decide the representation format for a response at runtime depending on the value of theÂ
User-AgentÂ contains information about the type of client who made this request.Â
Accept-Encoding/LanguageÂ tells about the encoding and language this client supports.
An HTTP response has the format shown in Figure 2:
Figure 2: HTTP response format.
â€œThe server returnsÂ <response code>, which contains the status of the request. This response code is generally theÂ https://en.wikipedia.org/wiki/List_of_HTTP_status_codes.
<Response Header>Â contains the metadata and settings about the response message.
<Response Body>Â contains the representation if the request was successfulâ€
Example sample response of post request
In the below image we are getting status code 201. So according to this status code request is completed and an issue has been created on given URL.
â€œCaching is the concept of storing the generated results and using the stored results instead of generating them repeatedly if the same request arrives in the near future. This can be done on the client, the server, or on any other component between them, such as a proxy server. Caching is a great way of enhancing the service performance, but if not managed properly, it can result in client being served stale resultsâ€.
â€œA RESTful service is stateless and does not maintain the application state for any client. A request cannot be dependent on a past request and a service treats each request independentlyâ€.
â€œThe uniform interface constraint is fundamental to the design of any REST service. The uniform interface simplifies and decouples the architecture, which enables each part to evolve independentlyâ€.
Links between resources
â€œA resource representation can contain links to other resources like an HTML page contains links to other pages. The representations returned by the service should drive the process flow as in case of a website. When you visit any website, you are presented with an index page. You click one of the links and move to another page and so on. Here, the representation is in the HTML documents and the user is driven through the website by these HTML documents themselves. The user does not need a map before coming to a website. A service can be (and should be) designed in the same mannerâ€.