A 1969 NASA publication entitled Computer Program Abstracts contains a summary of a real-time display control program sold by IBM (only $310! Plus $36 if you want the documentation). The advertisement says that this program was designed as an operator-application programming interface – in other words, an API.

Application Programming Interfaces (APIs) have been around for about as long as computer code has. Conceptually, it is just a way for two different pieces of code (or a human and some code) to interface with each other. A class that provides certain public methods that other code can call has an API. A script that accepts certain kinds of input has an API. A driver on your computer that requires programs to call it in a certain way has an API.

However, as the internet grew, the term API narrowed in focus. Almost always now, when someone talks about an API, they are talking about a web API. That is the context I will use in this book. A web API...

Some calls to APIs can change things on the server, while others return data without changing anything. The terms safe and idempotent are used to describe the different ways that API calls can affect data. These terms might sound a bit intimidating, so in order to better understand them, let’s look at an illustration that uses something we can all understand: LEGO pieces.

Imagine that there is a table with a couple of LEGO pieces on it and I’m sitting by the table. I represent an API, while the table represents a server, and the LEGO pieces represent objects. If you come along and want to interact with the LEGO, you must do so through me. In this illustration, the LEGO pieces represent objects on a server, I represent an API, and you represent a client. In picture form, it looks something like this:

Figure 1.1: Representation of a server and a client connected by an API

You are going to be the client in this imaginary relationship...

Postman can be run on the web or as a desktop application. The functionality and design are similar between the web and desktop applications, but in this book, I will mostly use the desktop application, so I would recommend you install it too. The app is available for Windows, Mac, and Linux, and installing it is the same as pretty much any other program you’ve installed. However, I would highly recommend creating a Postman account if you don’t already have one. Creating an account is totally free, and it makes it a lot easier to manage and share your work. The free account of Postman is very generous in what functionality it enables. Postman does have some enterprise or advanced-level features that require a paid account, but all the examples in this book will work with the free features of Postman. However, if you don’t have an account at all, it will be difficult to follow along with some of the examples, so I would strongly recommend that...

The request tab in Postman provides a lot of information about the various pieces that make up an API request. Each of these pieces plays an important part in sending and receiving data with an API, so I will walk you through each one in turn. Some parts of an API request are optional, depending on what kind of request it is and what you are trying to do with it, but there are three pieces that are required for every API request. Every API request needs an endpoint, headers, and an action; let’s look at those next.

API endpoints

Every web-based API request must specify an endpoint. In the Postman requests tab, you are prompted to enter the request URL. Postman asks you to enter a URL because an API endpoint is just a URL. We use the term URL so much that we can sometimes forget what it stands for. URL is an acronym for Uniform Resource Locator. The endpoint of an API call specifies the resource, or the “R” of the URL. In...

Books are a great way to grow and learn. You are reading this book, so I don’t think I need to convince you of that! However, reading a book (or even three or four books) on a topic does not mean you understand that topic. There is theory and then there is putting it into practice. These are two very different things, and if all you do is read about a topic, you will feel like you know that topic, but that will be more of a feeling than a reality.

If you want that to be a reality and you don’t just want this book to be another piece of theoretical knowledge bouncing around inside your head, you need to put into practice the things that you are learning.

Hands-on exercises might feel like they are slowing down your reading, but working through them will actually help you learn faster and get more out of this book. But enough talking about it. Let’s get to some exercises!

In order to help you with getting...

We have started with the mechanics of how to make API requests, but this book is about API testing, so now that you know some of the basics of how an API request works, let’s look at some of the things to consider when you test an API. One important aspect of testing is exploratory testing.

Beginning with exploration

I can still clearly remember the first time I saw a modern web API in action. The company I was working at was building a centralized reporting platform for all the automated tests, and I was assigned to help test the reporting platform. One of the key aspects of this platform was the ability to read and manipulate data through a web API. As I started testing this system, I quickly realized how powerful this paradigm was.

Another part of my job at that time was to work with a custom-built test automation system. This system was quite different from the more standard test automation framework that many others in the company...

There are several types of APIs commonly used on the internet. Before you dive too deep into the details of using Postman, it is worth knowing a bit about the different kinds of APIs and how to recognize and test them. In the following sections, I will provide brief explanations of the three most common types of APIs that you will see on the internet.

REST APIs

We’ll start with what is probably the most common type of API you’ll come across on the modern web, the RESTful API. REST stands for Representational State Transfer and refers to an architectural style that guides you in terms of how you should create APIs. I won’t go into the details of the properties that a RESTful API should have (you can look them up on Wikipedia if you want, at https://en.wikipedia.org/wiki/Representational_state_transfer), but there are a few clues that can let you know that you are probably testing a RESTful API.

Since RESTful APIs are based on...

Let’s pause for a minute to consider everything we have gone over in this chapter. You’ve installed Postman and already made several API requests. You’ve learned how API requests work and how to call them. I explained some basic testing considerations and gave you strategies that you can start to use right away in your day-to-day work. You also got to make calls to GraphQL, SOAP, and REST APIs and learned a ton of API terminology.

You now have something firm to hold onto as we proceed through the rest of this book. I will take you deep into a lot of API testing and design topics and help you get the most out of Postman, but in order to get the most out of it and not feel frustrated, it would be good to make sure you understand the topics covered in this chapter.

Take a minute to ask yourself the following questions:

• Would I feel comfortable reading an article on API testing? Could I follow along with the terminology used?
• What...