Understanding web services

After reading this article, you will find out everything you need to know about web services to get you started: when, how, and what they are used for, the benefits of using them, and the REST architecture and the SOAP messaging protocol.

Let’s start with the beginning.

What are web services?

With the evolution of the Internet, the idea of a web service developed.

A web service consists of a collection of operations accessible through the network and the HTTP protocol. Once publicly available or through an access list, the benefits are accessible by one or more applications. It provides communication between different software applications that can run on other platforms. In general cases, it represents the web interface to a database.

Modern web services support both synchronous and asynchronous functionality.

The REST Concept

It is a simple architectural style based on Web and HTTP standards, becoming even more used than the SOAP model.

There are five main HTTP methods used in defining the operations of a RESTful web service:

• POST – creating a resource;
• PUT – updating the status of a resource;
• PATCH – partial update of the help;
• GET – reading / returning a resource without modifying it;
• DELETE – deleting a resource.

Resources can be represented in several formats: JSON or XML.

Web Services are a scalable architecture because it separates the client application’s responsibilities from those of the server. A stateless model because the server does not maintain the client’s status.

Web Services are often used with a caching system for entities that do not suffer much change. This leads to an increase in the response speed of the web service.

JSON message example:

{
“first_name”: ”Ioan”,
“last_name”: ”Pop”,
“age”: 32,
“benefits”: [“scalability”, “interoperability”, “distribution”],
“address”: {
“city”: ”Baia Mare”,
“street”: “Mihai Eminescu”,
“number”: 23
}
}

About SOAP (Simple Object Access Protocol)

SOAP was the first protocol for connecting to SOA (Service Oriented Architecture) web services. SOAP is built over the XML specification and uses HTTP for transport.

A SOAP message is defined as a header structure and a body element. The header can contain authentication information or the definition of complex data types. The body element describes web methods and information about their parameters.

SOAP Envelope:

<soap:Envelope xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance>
<soap:Body>
<AWeserviceResponse xmls=http://tempuri.org/>
<AWebServiceResult>string</AWebServiceResul>
<AWebserviceResponse>
<soap:Body>
</soap:Envelope>

Best development practices

Versioning

Launching a new version of the web service that is not backward compatible with the previous one requires versioning the web service and maintaining both versions for as long as the customers adopt the new version.

Documentation

Web services should display metadata information about the operations they can perform. Each web method should be described by HTTP Method, URI, Accept and Content-Type HTTP Request Headers, possible HTTP Response codes, custom headers, sample response, and sample request bodies.

Logging

The log information should be grouped in the same section of the request and printed at the end to make it easier to find them in the log files.

Error handling

Errors must be reported to the client via HTTP Status Codes:

200 Ok – Successful

400 – Bad Request

401 – Unauthorized

403 – Forbidden

404 – Not Found

405 – Method not allowed

500 – Internal Server Error

503 – Unavailable Service

URI Design

URIs should be concise, easy to remember, unambiguous about the managed resource, and constructed of nouns describing the resource, not verbs describing the action. The action is described by HTTP Request Methods which implicitly describes the type of action performed on the resource. It is harder to change the URIs of a web service once it is published and used by clients. URI /client/{id}/message/{msg_id}

Benefits

Interoperability

Integrating with web services offers a viable solution when working with different systems, legacy systems, or applications in other programming languages. This issue has received considerable attention since the 2000s.

Ease of use

Web services are built to be accessed through the web just as an HTML page is accessed through the Internet.

Reuse

A client application can use several web services, adding value to information management. Through Web Services, you can integrate different applications, especially legacy systems.

Distribution

Distributing a web service using a server with synchronous or asynchronous features is simple. At the same time, a new version of the service can be installed and become accessible in a short time.

Quality

Once built, web services are tested independently of client applications, which is done in a shorter time than monolithic applications.

Cost

Once a set of web services is exposed, client applications are developed much more accessible and lower in cost due to the shorter development and integration time.

Why use web services

• To provide point-to-point integration;
• To manage legacy assets;
• To sell Software-as-a-Service to your clients;
• To provide your business web APIs to different applications inside your organization;
• To reduce development costs.