Web Services vs APIs
When the first publicly available web servers launched in early 1991, few people understood the weight of what was to come. Today, the Internet is an incomprehensibly massive highway of data exchange, and it is challenging to imagine our lives without it.
But in 1991, it was just a collection of a few web pages that were hard to find and even harder to reach due to the era’s slower connection speeds.
Even after Yahoo Search, a function that would allow people to search a human-curated directory of web pages, launched in 1995, many were still unsure of what the Internet had to offer. In 1998, Google launched its now-ubiquitous search engine, allowing people to surf the entirety of the web using an automatically-generated directory.
Suddenly, people began talking to each other through email and messaging services like AOL Instant Messenger (AIM). Then, social media like Twitter and Facebook became a focus for many. People began to understand the power of this tool and how it could change everyday life.
None of these developments in the early Internet era would have been possible without web services and Application Programming Interfaces (APIs). Both web services and APIs allow developers to create applications that interact with each other or different datasets.
The difference between a web service and an API is often confusing, and many incorrectly use the two terms interchangeably. While web services and APIs are related, they are not the same and serve different purposes for developers. Today, we will dive into the difference between the two and what situations would be best for each service.
Definition of Terms
Before we dive into today’s topic, let’s look at some of the terms we will be using:
- Hypertext Transfer Protocol (HTTP) is an application layer protocol for distributed, collaborative, hypermedia information systems.
- Extensible Markup Language (XML) is a markup language that defines a set of rules for encoding documents in a human and machine-readable format.
- Web Services Description Language (WSDL) and an XML-based interface description language describe the functionality offered by a web service.
- Simple Object Access Protocol (SOAP) is an XML-based messaging protocol for exchanging structured information between computers.
- Representational State Transfer (REST) is a software architectural style created to guide the design and development of the World Wide Web.
- gRPC Remote Procedure Calls (GRPC) is an open-source remote procedure call developed at Google in 2015.
- GraphQL is an open-source data query and manipulation language for APIs and a runtime for fulfilling queries with existing data.
- JavaScript Object Notation (JSON) is an open standard file format and data interchange that uses human-readable text to store and transmit data.
Web Services
A web service can be broadly defined as an application that exposes an HTTP interface so other applications can interact with it. However, stricter definitions say that a web service can only expose WSDL, SOAP, and XML. These definitions are often outdated as they fail to include other types of interfaces like REST, GraphQL, and GRPC.
Simply put, a web service is a way for machines to communicate with each other using various networks and servers. A web service includes a web server that’s listening for requests from other computers, sending them the necessary information using JSON, XML, or HTML files upon receipt of a request.
The fact that a web service requires a network to use is an essential distinction between web services and APIs.
In general, all web services are APIs, but not all APIs are web services.
Web services vary widely in size and scope, from small internal line-of-business apps to large public web APIs. Amazon Web Services (AWS), Azure, and Google Cloud are some of the largest public web service providers. Their web services let you do anything from anomaly detection and language translation to video transcoding.
Even better, the cloud vendors don’t just offer web services — they also provide infrastructure to help you run your web services in many ways, including on Virtual Machines (VMs), serverless functions, and containers.
APIs
An API is an interface that defines interactions between multiple software applications or mixed hardware-software mechanisms. APIs are a more general concept, basically referring to any method an application or library uses to make itself available to developers or other applications. These interfaces can take the form of a web service, but they do not have to.
The crucial distinction between a web service and an API is that we can use APIs offline and locally, while we must use a web service online. Because you can use APIs on the same machine instead of strictly over a network connection, some APIs do not require a network to be able to interact with them.
In general, when a developer mentions an API, they often refer to a web API accessible over the Internet, much like a web service.As previously mentioned, other applications may expose an API using Unix sockets, shared file access, or a message queue on the same machine, which is never the case for a web service.
An example of a local API is the Component Object Model (COM) used in Windows machines. COM is a binary interface standard for software components that Microsoft originally introduced in 1993. You can learn more about COM in its documentation.
An Example of the REST API Architecture
Next, let’s look at an example of a REST API that is both a web service and an API.
Computer scientist Roy Fielding defined the REST architectural style in his Ph.D. dissertation in 2000, Architectural Styles and the Design of Network-based Software Architectures. REST defines a set of constraints for how both web services and APIs should interact with each other to stay efficient and accessible. REST has been guiding the way developers have been building web services and APIs since its introduction.
We can consider any web service that obeys the constraints of REST to be RESTful. Making a REST call is an excellent example of a system that is simultaneously a web service and an API — it is a web service because it runs over a network, but we could also use it locally among two applications on the same machine.
A REST request consists of two required components and three optional components. The required components are:
- http://example.com/api
- HTTP Method [GET, PUT, POST, PATCH, DELETE]
The optional components are:
- A header with additional information that the client may need to pass along to the server to ensure that its request is fulfilled properly
- Parameters to provide the variable fields that alter and define the response that the client will receive
- The body to provide any additional information that the service must pass along to the server
As a fun example, let’s say that you’re interested in the multiplayer game Rocket League. One great site for accessing data about professional Rocket League play is Octane.gg. Let’s make a call to the Octane API and request some data about a player.
We structure our REST call as follows:
HTTP Method: GET URL: https://zsr.octane.gg/players
Parameters: id=3dcf-jstn
This call gives us the basic information about any professional player with their ID specified.
Since we cannot make POST calls to a private database, let’s look at a slightly more complex GET call. This time we request the match data for the 2019 World Championship final games.
HTTP Method: GET URL: https://zsr.octane.gg/stats/teams/events
Parameters: stat=goals&team=23a0-nrg-esports&match=6744-nrg-esports-vs-team-vitality
If we use an API tester such as reqbin, we can see that the output of this call looks like this:
{
"stats": [{
"team": {
"_id": "6020bc70f1e4807cc70023a0",
"slug": "23a0-nrg-esports",
"name": "NRG Esports",
"image": "https://griffon.octane.gg/teams/nrg-esports.png"
},
"events": [{
"_id": "5f35882d53fbbb5894b430f9",
"slug": "30f9-rlcs-season-8-world-championship",
"name": "RLCS Season 8 World Championship",
"region": "INT",
"mode": 3,
"tier": "S",
"image": "https://griffon.octane.gg/events/rlcs.png",
"groups": ["rlcs", "rlcs19", "rlcs19worlds", "rlcsworlds", "rlcs8"]
}],
"players": [{
"_id": "5f3d8fdd95f40596eae23d6f",
"slug": "3d6f-garrettg",
"tag": "GarrettG",
"country": "us"
}, {
"_id": "5f3d8fdd95f40596eae23d9b",
"slug": "3d9b-turbopolsa",
"tag": "Turbopolsa",
"country": "se"
}, {
"_id": "5f3d8fdd95f40596eae23dcf",
"slug": "3dcf-jstn",
"tag": "jstn.",
"country": "us"
}],
"opponents": [{
"_id": "6020c370f1e4807cc702fc9c",
"slug": "fc9c-team-vitality",
"name": "Team Vitality",
"image": "https://griffon.octane.gg/teams/team-vitality.png"
}],
"startDate": "2019-12-15T11:01:11Z",
"endDate": "2019-12-15T11:49:21Z",
"games": {
"total": 7,
"replays": 7,
"wins": 4,
"seconds": 2193,
"replaySeconds": 2193
},
"matches": {
"total": 1,
"replays": 1,
"wins": 1
},
"stats": {
"goals": 14
Octane.gg sends back the information that we asked for in JSON format. JSON is easily human readable: we can see that the match was on December 15, 2019, and NRG eSports defeated Team Vitality four games to three.
Calls like these provide tons of information for developers to use within their applications. The structure of most APIs is very similar, if not identical, to the REST API format.
This continuity creates a clear and concise way for developers to interact with web services all over the Internet. As developers, we can use APIs and web services to empower our applications and feed them the data they need.
Conclusion
In summary, while web services and APIs achieve similar goals, they also have fundamental differences that set them apart. Web services are always online and require a network to function. We can request APIs over a network, but we can also create them and use them locally to allow applications to access each other on the same machine.
We also covered REST, which is the architecture used by most web services to format client calls to their API. REST supplies a seamless architecture for both API builders and application developers to use.
Web services and APIs have empowered developers to create the Internet that we know and love today. Sometimes it may be hard to see, but so many aspects of the Internet rely on web services and APIs to provide data and methods that support a wealth of applications.
As developers, we must take advantage of the power these two systems offer, understand their differences, and create the products we need!
If you are looking for ways to further your learning and experimentation with APIs and web services, but don’t know where to start, check out some of GrapeCity’s offerings — such as Wijmo, a UI component collection that is available in React, Angular, and Vue! Wijmo has a ton of valuable features, such as the ability to create flexible charts and data grids with an elastic and extensible API.
Wijmo is super lightweight and won’t leave a massive footprint on your project. GrapeCity also offers services like ComponentOne, an award-winning .NET and JavaScript controller with many powerful server-side APIs for you to use!
MESCIUS inc.