Working model of the web service

The web service is based on the request-response model. When services interact with each other, one passes an input to the other. The service accepts the input in a particular format, processes the input, and returns the response in a format that the receiving client can understand, as shown in the following diagram:

Let's say we have a web service that takes input data and returns output data in exchange. The data that we input to a web service is called the request and the data that we get in exchange for an input from the web service is the response. When an application wants to consume the web service, it has to send an input, or trigger a call, in order to start consuming the web service.

Typically, the application sends a request in a standard format that the web service can understand for processing. When a web service returns the response, it sends it in a standard exchange format that the application that sent the request can understand.

The standard format of request and response is what makes web services platform independent. This is how a Python-based application can talk to a Java or Kotlin application.

In the web services world, there are two standard formats for request and response:

  • JSON: JavaScript Object Notation (JSON) data is what JavaScript represents as an object. For example, a sample JSON payload looks like this:
{
"loginId":"[email protected]",
"name":"John",
"city":"Bengaluru"
}

This example defines a JSON object with a comma-separated list of name-value pairs. A JSON object is surrounded by curly braces, { and }. A name-value pair consists of a field name (in double quotes), followed by a colon (:), followed by the field value.

JSON is easy to read, write, and parse while processing the request.

  • XMLExtensible Markup Language (XML) is yet another way to represent structured information. For example, a sample XML payload looks like this:
<person>
<loginId>[email protected]</loginId>
<name>John</name>
<city>Bengaluru</city>
</person>

The JSON and XML data formats are supported by most of the web services of different platforms. These are common in modern applications. This is how web services became independent; by making the request and response independent of the platform.

Once we have the common format for data exchange, we can look at how to define the request structure and how to interpret the response from the web service. Each web service will have a service definition that talks about what a web service can offer.

A service definition specifies the standard request-response format that is used, whether this is JSON or XML. It specifies the structure of the request, how a consuming application can create a request, and what a request format would look like. This also defines the response structure, which is the structure of the response returned by the service. In addition, the service definition specifies the endpoint with which a service can be invoked.

There are other alternatives to JSON/XML for data exchange between the services, such as BSON (short for Binary JSON), MessagePack, and YAML (short for YAML Ain't Markup Language). BSON is a binary-encoded format of JSON-like data. It also contains extensions to JSON to represent the data types that are not part of the JSON specification. MessagePack is also a binary-encoded JSON-like data exchange format. BSON and MessagePack are binary encoded and not human readable. YAML is a unicode-based data exchange format and is in human-readable format.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset