web services

What are web services?

Web services are a type of internet software that use standardized messaging protocols and are made available from an application service provider's web server for a client or other web-based programs to use. These services are sometimes referred to as web application services. They provide powerful, flexible interoperability, enabling machine-to-machine interactions across a network even with machines and software stacks not designed to work together natively.

A web service supports a specific task or set of tasks. A formal description specifies the web service and includes all the details needed to interact with it, such as message formats and protocols. This lets almost any hardware or software stack use the service regardless of the underlying platform and programming language used to build the service. This independence enables complex cross-platform interactions that simplify and streamline data access and transactional behavior.

Web services range from major services such as storage management and customer relationship management to more limited services such as furnishing a stock quote and checking bids for an auction item.

Users can access some web services through a peer-to-peer arrangement rather than a central server. Some services can communicate with other services. Middleware generally accommodates this exchange of procedures and data. The need for web services emerged as all major platforms were able to access the internet, but different platforms couldn't interact with each other. Web services took platforms to the next level by publishing functions, message, programs and objects to the rest of the internet.

Types of web services

Web services are built using open standards and protocols to integrate with various applications. The protocols web services use include the following:

  • Extensible Markup Language. XML is used to tag, code and decode data. XML-remote procedure call, or XML-RPC, is a basic XML protocol using HTTP to exchange data and communicate between client and server systems.
  • Simple Object Access Protocol. SOAP is an XML-based web service protocol used to transfer data using SOAP messages. The SOAP protocol was developed to enable different programming languages to communicate quickly and with minimal effort using HTTP or Simple Mail Transfer Protocol (SMTP).
  • Web Services Description Language. WSDL is used to tell the client application what's included in the web service and how to connect. Variations on WSDL include Web Services Conversation Language and Web Services Flow Language.
  • Representational State Transfer. Based on HTTP, REST provides interoperability between devices and the internet for application programming interface (API)-based tasks. While not all RESTful web services use the REST protocol, applications built with RESTful APIs are more lightweight, manageable and scalable.
  • Universal Description, Discovery and Integration. UDDI is an XML-based standard that lists and details what services are available in an application. It makes web services discoverable to other services and facilitates digital transactions and e-commerce.
A graphic showing how XML and HTML compare.
UDDI is an XML-based standard that shows what services are available in an application. It also makes web services discoverable to other services.

How web services work

Web services let different organizations or applications from multiple sources communicate without the need to share sensitive data or IT infrastructure. Instead, all information moves through a programmatic interface across a network. This interface can then be added to a GUI, like a webpage, to deliver specific functionality to users. This means web services aren't specific to one programming language or operating system (OS) and don't require the use of browsers or Hypertext Markup Language (HTML).

Most web services operate using a typical client-server behavior. An application running on a client computer or mobile device has access to a network such as the internet. A server provides data and compute capabilities.

The process includes the following three steps:

  1. The client sends a request to the server that includes details and data the web service requires. The data can be in any common format such as JavaScript Object Notation (JSON) or XML.
  2. The server side receives and authenticates the request, parses the required details, processes the request and accesses any appropriate results.
  3. The server accesses any appropriate results and sends them back to the client application, which displays them in a form and style appropriate for the application.

The key to this process is that the client application is loosely coupled -- meaning it has no relationship at all -- to the server or data services. The web service lets the client communicate with the server. As a result, many applications, written by countless developers and businesses, can use a web service to access compute or data services.

Websites that use web services to access and display map data from a major service like Google Maps are an example of these client applications. None of those websites know or care how Google Maps works. It's the web service that provides a common means of interacting with Google Maps to obtain Google Maps data.

Characteristics of web services

Web services typically use XML for information exchange and have certain other common characteristics, including the following:

  • They're accessible to users over the web, allowing web services to be published, discovered and invoked.
  • They're modular, so the services can be used independently or aggregated in an arranged or chained setup to form more complex sets of web services. This is an important means of software modularity and reusability.
  • Open standards let them interoperate over any programming language or OS.
  • They're self-contained so no additional software is needed on the client side other than a programming language with XML and HTTP support.
  • They self-describe, using common XML semantics so a WSDL file provides all the information needed to invoke a service.
  • They're discoverable through a common mechanism such as UDDI.
  • They're often open source because of the common underlying standards.
  • They're loosely coupled to and have no dependency on the underlying server-side implementation.
  • They're independent of any user interface in favor of code-only programmatic access and operation.

Uses of web services

Web services are used for many tasks, with the most common being reusing code, delivering services, and connecting existing programs.

Reusing code

With its universal communication protocols, the web service method can help developers segment applications into components that can be reused for various needs. For example, several programs might need a conversion tool or a reporting function. Rather than build these functions into every program, they can be built as standalone services and made accessible through web services. Other programs can then use the appropriate web service to invoke the standalone services as needed. This results in smaller, simpler applications that are faster to develop and easier to test and maintain.

Delivering services

Businesses wanting to get revenue from data and compute services, often use data sources as a business service that can be provided to consumers. Web services are a popular mechanism for exposing those services to outside developers, tracking web service use and generating billable activity based on web service access.

Connecting existing programs

Web services can be used to link data between different platforms. Because all applications can include a web services component, this can turn any program into a fully interoperable one. Wrapping an existing or legacy application in a web service is an effective way to convert an older application into a network-capable application, which can modernize it without having to recode it from scratch.

Examples of web services

The following examples show how web services are used in real-life applications:

  • Google search. When computer users access the Google search engine, their search terms or query is passed to the Google search engine. The engine performs the search and returns search results to the user's web browser. The user then selects from the available search results or enters a new search query to refine and continue their browsing.
  • Google Maps. When using Google Maps, users provide their location and desired destination. The service calculates the most appropriate route and offers directions and a detailed map delivered to the user's web browser. Additional services can be invoked to add supplemental data, such as weather and traffic conditions.
  • Amazon. This large, well-known shopping site lets users detail the product type, model, manufacturer or other details for which they're looking. Amazon displays the available product options and lets users place orders and pay for using Amazon's web services.

These are a few of the many examples of web services available. Any business with data or compute services to offer can expose those resources through a web services interface or API. This can allow an organization to exchange information between enterprise applications, interact with business partners and users, and bill for web services access and use to generate revenue.

Advantages of web services

Web services offer many compelling advantages, such as the following:

  • Simplicity. Web services use standardized technologies such as WSDL, XML and HTTP.
  • Interoperability. The key to web services is abstraction, allowing systems to interoperate without any knowledge of the underlying systems or architectures involved.
  • Cost-effectiveness. The simplicity and well-established technologies involved make web services fast and inexpensive to build, deploy and maintain.
  • Modularity and reusability. Web services allow any application to use routine features and functions as web services rather than incorporating them into each application. This lends itself to software development that's modular and reusable.
  • Independence. Web services maintain little or no dependence between the client and server sides of an exchange. This makes web services stateless in a way that allows for network disruption and data loss without compromising application performance.
  • Security. Web services use authentication, authorization, encryption and other security measures to protect the data being transmitted between clients and servers.

Challenges of web services

As web services proliferate, concerns include the overall demands on network bandwidth and, for any particular service, the effect on performance as demands for that service rise. Several new products have emerged that let software developers create or modify existing applications that can be published as web-based applications. However, there are other potential issues with web services, including the following:

  • Connectivity. Web services are contingent on the availability of network connectivity. Besides bandwidth limitations, issues such as network reliability and latency can contribute to performance problems. And network disruptions and downtime can render a web service unavailable.
  • Overhead. Although web services use standardized, well-established communication layers and protocols, these technologies also introduce some processing overhead that can impair communications performance. In addition, resource consumption associated with web services can raise operational overhead and costs.
  • Complexity and compatibility. Web services can be complex entities to build, implement and maintain. Varied communication protocols, data formats and security precautions increase that complexity. Web services are basically software with version control, often requiring applications to update and upgrade over time as versions evolve and grow.
  • Security risks. While security tools exist to protect data exchanges through web services, those security measures must be implemented properly and tested thoroughly to prevent privacy issues, data breaches, unauthorized use and other attacks.
  • Troubleshooting. Web services enable the creation of more complex communication and data exchange environments. This makes troubleshooting more difficult because problems can arise at the client, the server, the network or the web service itself.
  • Vendor lock-in. When using a third-party provider's web service, a business can become dependent on that provider. This type of vendor lock-in makes it difficult or impossible to use alternative web services in the future.
A list describing key aspects of vendor lock-in.
Vendor lock-is a potential downside of using web services.


Web services are all about accessing and exchanging information. These services depend on data protocols, the rules that define how data is handled and moved so both sides of a communication link can understand it. SOAP and REST are the two most popular data exchange protocols.


SOAP is highly structured. It uses an XML data format and typically HTTP or SMTP for data transmission. SOAP is stateful and uses WSDL to describe the web service model that defines how its requests and responses are structured; it includes well-defined security standards.

SOAP-based web services are easier to consume than REST. They involve more standards and support advanced capabilities such as distributed computing. However, SOAP web services are more complex to develop, implement and support than REST.


By comparison, REST is a flexible, stateless protocol that supports data exchange in varied formats. REST is object-based and uses HTTP for key processes such as DELETE, GET, POST and PUT. But REST formally defines little else, allowing data transfers using plain text, HTML, XML and JSON. REST is considered a lightweight protocol that's easier to build and understand than SOAP services. However, REST is typically limited to point-to-point communications, and the lack of deeper standards can lead to performance and interoperability limitations.

It's important to note that SOAP and REST protocols are both popular and used widely for web services. The question is not which is better, but rather which protocol is best-suited to the web service being developed.

APIs vs. web services

There are many similarities between web services and APIs. The terms are often used interchangeably, though this is technically incorrect.

  • Web services are software used to connect systems and software across a network. They're built from open, well-established protocols and standards and are typically heavier and demand more bandwidth or compute overhead than APIs.
  • APIs are software mechanisms used to connect systems and software, regardless of the presence of a network; an API can run and connect applications running on the same hardware. They use a set of protocols and definitions that developers describe. APIs are typically lighter-weight and more resource and bandwidth efficient than web services.

There is considerable overlap between web services and APIs. Essentially, web services are a subset of APIs. A web service is a type of API, and most web services provide an API. One way to implement an API is as a web service, but not all APIs are web services.

Learn more about building a successful enterprise API strategy in this comprehensive guide.

This was last updated in March 2024

Continue Reading About web services

Dig Deeper on Application management tools and practices

Software Quality
Cloud Computing