Understanding web services

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, but also about 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 services are accessible by one or more applications. It provides a means of communication between different software applications that can run on different 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:

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

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

Web Services are a scalable architecture because it separates the responsibilities of the client application 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 contains the definition of web methods as well as 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 a page of 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, any custom headers, sample response, sample request bodies.

Logging

The information in the logs should be grouped in the same section of the request and printed at the end of the request 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, constructed of nouns describing the resource, and 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

When we have to work with different systems, legacy systems, or applications in different programming languages, integration with web services offers us a viable solution. 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 are able to integrate different applications and especially legacy systems.

Distribution

It is simple to distribute a web service using a web server with synchronous or asynchronous features. 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 easier 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;
Comments (0)
Join the discussion
Read them all
 

Comment

Hide Comments
Back

This is a unique website which will require a more modern browser to work!

Please upgrade today!

Share