In 2020, the analyst in the developer economy SlashData conducted the 19th Developer Economics survey that reached nearly 17,000 developers worldwide. According to it, almost 90 percent of the respondents are actively using web services and APIs, while only 11 percent reported not using them at all. This fact shows how critical web services have become in modern software development.
In this blog, we will take a look at what a web service is, what its functions are, elaborate on web service types, and compare and contrast the characteristics of a web service in relation to an API.
What is a Web Service?
A web service is a software system with open protocols that has a unique URL address and maintains communication between two applications via the internet. Being platform and technology independent, a web service acts as a mediator that can connect all types of applications across the web regardless of the programming language they are written in. For instance, Java applications can be connected to .NET applications. Such compatibility is possible due to open standards of web services, while the communication happens via the data exchange formats XML/JSON and the protocols of web communication HTTP/HTTPS.
Standard client-server communication model
There are two main components of such communication: client (a service consumer) and server (a service provider). Usually, a client requests the server to get or save the data. Let’s say you want to find some place on Google Maps from your mobile phone. In this case, the application on your mobile device is a client while Google Maps service is a server that returns the required data (specific location) upon your request.
Companies actively use web services for common tasks, for instance, when integrating payments to their platforms or while registering users on a new website via Facebook or Google credentials. Asking Siri or Alexa the weather forecast and using Google Maps are other examples of web services in a day-to-day routine.
Web services vs APIs: Are they the Same?
Despite being often used interchangeably, a web service and an API are two close but slightly different concepts.
Application Programming Interface (API) is a set of software functions and procedures that enables data transmission between any kinds of software products. To put it simply, one can compare an API with a language used by two separate systems to communicate, but instead of verbal signals and symbols, there is a programming code that enables connection between devices.
API is a broader term than web service. It describes a communication layer between all types of systems, transmitting data both via web and offline channels. For instance, such APIs as DirectX or Vulkan are operating system interfaces that don’t use the web to exchange information.
A web service is an API that operates only via web communication. So, we can say that all web services are APIs; however not all APIs are necessarily web services. In this article, we may use both API and web service terms implying that we are talking about web-based APIs.
By the way, we have a video about the basic principles of API. Feel free to enjoy it:
API explained
Web Services Use Cases and Examples
Our everyday life is surrounded by the work of web services. They are used in many tasks that have already become routine to us, such as making online payments, logging-in via social media platforms, booking flight tickets, and so on. A web service may be compared to a waiter at a restaurant that speeds up the meal selection process and directly communicates with the kitchen staff for you.
Let's have a closer look at some real-life use cases of web services.
Payment Gateways
Payment gateways serve as an intermediary between customers (users who want to purchase a particular product or service online), businesses (shops and retailers that sell their goods via the Internet), and payment processors that handle transactions. After the order is placed, the payment gateway has to verify whether the user’s card details are secure and if the needed amount of money is available. An online transaction goes via a payment gateway to the payment processor, bank and, finally, the money appears in the retailer’s bank account.
To connect a retailer platform (e.g. eCommerce website) with a payment processor, a web service is used. Payment web services ensure a secure payment for online retailers or web applications, providing them with the ability to accept credit cards.
Let’s take Paypal, a popular online payment provider, which supports gateway integration and actively uses web services to help its clients securely conduct mobile and online payments. Paypal REST API serves for transaction workflows like payments, orders, invoicing, subscriptions etc., using the HTTPS channel and JSON responses.
Social Plugins
Today it’s common to log-in using social media account credentials. For instance, if you want to quickly register on a new website. It’s possible to go the traditional way and enter all the necessary personal information. Since it might be quite time-consuming, that's where the social plugin option becomes truly convenient.
Its working principle is simple. Each time someone launches the app, it uses a web service to verify if this user was already logged in via a social platform. If that’s not the case, after the “Log-in Using XYZ” button is pressed, a pop-up window requests to confirm this person wants to proceed with the social plugin. After the confirmation, the API sends the identification information back to the app.
Logging-In to HackBook via Facebook Credentials, Source: Facebook
Let’s take the Facebook Login API. Available on multiple platforms, such as iOS/Android, web, desktop applications and even Smart TVs or the IoT, this plugin allows users to register using the existing Facebook credentials.
Travel and Booking
Travel booking websites and online travel agencies distribute travel products (flights, accommodation, tours, etc.), providing their customers with a variety of options to choose from. There is no need for a travel distributor to contact each airline or a hotel separately by email to check availability and rates. They use travel and booking web services and APIs offered by such aggregators as Global Distribution Systems to get access to a wide travel inventory. How? Acting like a bridge between a booking app and other resources (flight/hotel suppliers and their APIs), travel and booking web services provide distributors with all the information about existing prices, help manage rates, and display travel deals.
For example, Amadeus, is a large traveltech company that offers travel data and online ticket reservations. Its set of web services allows distributors to fetch travel data from hundreds of travel providers and enable travelers to book those services.
Maps Services
Map services like Google Maps also actively implement web services that use HTTP/HTTPS requests to return data back to an application using XML or JSON data interchange formats.
GoogleMaps platform has many separate APIs for maps, routes and places, Source: Google
GoogleMaps API is used by the company to provide many kinds of data (location, navigation routes, landmark data). This helps global businesses integrate map data in their applications and provide services to their customers, suppliers, and delivery companies. Moreover, data offered by Google Maps is actively used by ridesharing applications like Uber or BlaBlaCar.
These are just a few examples of how web services are used. This list isn’t even close to being exhaustive.
Types of Web services and Architectural Approaches
Technically speaking, a web service can be implemented in many ways, but generally there are three common types of architectures -- RPC, REST, and GraphQL. We didn't include the SOAP architecture, since it is already considered a legacy approach. But you still can read our article about it.
Web service architectures
RPC (Remote Procedure Call)
Format: XML/JSON/Protobuf
Where is it used?: command and action-oriented APIs, remote error logging, monitoring program control, client/server apps on Windows OS
Remote Procedure Call is the earliest and most straightforward approach among all forms of web service types. How does it work? A client sends certain commands to a remote server. After receiving the message, the server performs the requested operation, afterwards sending the result back to the client. So, basically, RPC allows a client to make a remote call of the needed procedures on a server, hence the name.
The sequence of events in RPC client-server model
For example, if a client needs to call a cab via an RPC web service it would send a command /CallCab, which activates a call cab function on a server.
As the simplest among now existing web service types, RPC normally uses only GET and POST HTTP methods to call specific functions on the server. GET is applied for receiving the data and POST for all other operations. So, the mechanism of communication between a server and a client consists only of the remote call of the server and getting the response from it.
However, RPC is outdated and, at present, it’s rarely used by web service developers as the world moves on with more complex protocols and architectural styles like REST or GraphQL that we discuss below. First, PRC is not really a standard, but rather an approach that lacks unity across different services. This means that businesses should expect that each web service will have its unique implementation, set of functions to call, and conventions to follow.
There’s a Google-backed spin on RPC architecture called gRPC that you can read about in our separate article.
REST (Representational State Transfer)
Format: XML/JSON/Plain Text
Where is it used?: public APIs, simple resource-driven apps
REST is the most popular architectural style to build web services. Its principles were developed in 2000 and at that time served as a flexible alternative to previously known machine-to-machine communication methods. Today, REST is believed to be the gold standard for public APIs and web services.
Client-Server-based REST model
While RPC suggests dealing with unique sets of methods for each web service, REST focuses on standard HTTP/HTTPS methods for all types of operations.
GET to retrieve data from service;
POST to create the new record;
PATCH to modify the record;
PUT to replace the record;
UPDATE to update the record;
DELETE to delete the record.
These methods are applied to resources, another foundational concept of REST services. A resource is an object that a client can access with a request. For instance, if a web service provides information on the restaurants available across different locations, then a resource would be a list of restaurants in a particular city. Each resource has its own URL that a client can access.
Having only HTTP methods to access and operate resources allowed the REST approach to achieve standardization so important in the connected world. Engineers across organizations don’t have to spend much time on learning the different methods and conventions each API suggests. Instead, they can apply universal techniques of web communication for any web service they must integrate with.
GraphQL
Format: JSON
Where is it used?: microservices, complex systems, mobile APIs
GraphQL is a web service architecture initially developed by Facebook for its own purposes in 2012. In 2018, it became open source and further on GraphQL has been led not by Facebook, but by the GraphQL Foundation. GraphQL was used in the development of such products and services as Airbnb, Shopify, GitHub, Pinterest, The New York Times, and others.
GraphQL coordinates the data from the client to the database
What does GraphQL do differently from REST? As we mentioned, REST offers to access data stored as resources via a URL. Each resource has its own URL. This means that if you have to collect data contained in several resources, you must access them individually via their own URLs. On the other hand, if you’re looking for a subset of data from a single resource, you still receive all data contained in this resource. These challenges are referred to as under- and overfetching.
For example, a REST web service offering restaurant details dedicates a resource to each restaurant. If a client needs to fetch only location data for a handful of restaurants it must access separate URLs of each restaurant in question, get all the details (location, description, cuisine type, etc.) and then retrieve the location data only.
GraphQL, on the other hand, suggests a single access point for all its data. All data fields (say, restaurant location, description, and cuisine type) are described in a schema, a set of available objects that a client can fetch from the server. Instead of fetching all details, a client can specify which data fields it’s interested in (e.g. location) and receive only the needed subset of information. Similarly, it can define which data fields must be modified if a client wants to change the data on the server side.
GraphQL became a common approach for those web services that exchange large volumes of different information and are concerned with speed and efficiency of communication.
Documentation of web services
As with every complex technical concept, web services have their own functionality, challenges, and possibilities. That is where we need comprehensive documentation to better describe what web services and APIs are and how to use them effectively.
API documentation is a set of tutorials, references, and use cases that introduces developers to web service and its functionality. Being a primary resource that explains the possibilities of a given API, this documentation is usually hosted in a particular section of the company’s website. Sometimes, it can be located in a separate API-focused portal.
When web services are used outside the company, these are public web services or public web API that are easily discoverable and can be reached in open access by any developers worldwide. In this case, API documentation has to be public and have open access accordingly.
There are three main types of API documentation:
Guides and Tutorials
Reference and Functionality, and examples and use cases
Guides, references, and examples help developers determine the possibilities of an API, used conventions, request and response examples.
The Future of Web Services
Out of all popular types of web services, GraphQL proves to be the most effective one and is expected to hold a leading position by frequency of use in the future. Among the globally renowned brands that actively implement GraphQL today are Airnbnb, Coursera, GitHub, Meta, Paypal, Twitter, and many others. However, both REST and GraphQL still have their preferred use cases. If it’s supposed to be a browser-centric service, REST would be a good fit. With general data exchange, especially common across B2B services, REST will be far below GraphQL in terms of efficiency and speed.
Sometimes, it’s also a great solution to mix several types of architecture to use the best characteristics from each of them. For instance, think about implementing both REST and GraphQL where REST would be responsible for web servers and GraphQL for backend services.
