Chapter 1 - Intro to API testing

Let's start our journey into API testing with a basic introduction to API's, and what they are. First of all, what does API stand for? API stands for Application Programming Interface, which basically just means that it's one piece of code talking to another piece of code.

This could be your website talking to a database back end, it could be a mobile application talking to an authentication service. There are all sorts of configurations that it could be, but it's essentially one piece of code talking to another piece of code.

The way that an API works is through a contract.

First of all, you have a request, which includes and endpoint, headers and a body. When the service receives this request, it responds with its own set of headers, body, and also a status code.

Let's look at an example of how this works.

Here we are on Amazon's' website, and let's say we're searching for something, it could be anything. Let's take a look at what's happening in the world of API's.

So, I've narrowed it down to a single API, the “Completion” which is actually called every time you type a letter into the search box. This has all the elements we were talking about.

We have the endpoint which is “suggestions.”
We have various parameters that are being sent along. This is the interesting bit here, prefix B.
And then we have a response. The response being its various suggestions for when I typed in B. Bluetooth headphones, et cetera.
We also have the headers, which are pretty basic, and the status code which was OK that means that the request was successful.

And if we go to the next instance of this API call, it's almost the same, but now in the parameters we have “BA.” And the response is BA things, bath bombs, baby wipes, etc.

And it keeps going with our parameter changing each time, which for our final search term it was “bag,” so now it's doing bags.

This is just a single example of an API in the wild, on Amazon, that's performing a service for Amazon customers to help them find what they want.

Even though the customer is the person who ultimately benefits from the API, in that case, it's important to remember that the end user for an API is actually the developer of an application.

The developers are the ones who are using the APIs to add functionality to their web pages, or their mobile applications, or whatever.

Things that are important about APIs for developers are:

That the APIs are correct, in that the contract is honored in the way that it's supposed to be.
That they provide value, that they're doing something that the application needs, to show information to the customer or to process data or whatever.
And that they're intuitive. Basically, meaning that the API should be easy for a developer to work with. In the same way that a good UI will be easy for a customer to navigate, a good API should also be intuitive for developers to program with.

One thing that's really crucial to remember, is that APIs are essentially public information.

Even though the Completion API that we saw on the Amazon site was meant for the developers to use, we, the public, were able to go and look at it. We were able to see the URL, and the parameters that were used, and we could potentially call that API outside of the Amazon website.

This is true for any API that's exposed through a web application, or a mobile application. So, when you're testing your APIs, you cannot assume that they'll always be accessed through the expected user interface. They could potentially be accessed from anywhere.

Many companies such as Twitter, Facebook and Spotify, have publicly documented APIs because they want to encourage developers to create applications that use their products.

For example, the Spotify API is very well documented. It shows the endpoints, search, and the request parameters. There are also instructions on how to use them. This is a really good place to look at how an API could work, and all the different parts. And they actually have a way that you can even try them.

I would definitely recommend looking at the Spotify documentation as an example of a real API and how all the different parts come together.

For the final part of our introduction, I just wanted to go over a few tools that will help you view APIs in various contexts.

First of all, you can view APIs in your browser, in Chrome, using the “View|Developer|Developer Tools.” Or in Firefox, using “Tools|Web Developer|Toggle Tools.” These tool sets are both very similar, so let's take a look.

# Viewing API in Chrome Browser

So here we are in Chrome. We just go to View|Developer|Developer Tools to bring the console up. Be sure to select the Network tab, because APIs are communicating over the network, then select XHR, which is for http requests. That's what our API requests are, http. And now we can see that when we type in the search box, our suggestions from Amazon come through.

We have headers, you can preview the request parameters, and you can see the response—all the stuff we were looking at before. You can also change where it is, or you can maybe get into a separate window. There’s timings, and all sorts of other tools within the Chrome developer tools.

# Viewing API in Firefox Browser

Firefox has very similar tool set, which we saw before: Tools|Web Developer|Toggle Tools. We see the same options again: Network and XHR. As you type things in, they appear. And you can see pretty much the same information.

I find Firefox to be easier to read, it's a little easier on the eyes, and seems to have better response formatting, but both sets of tools are essentially the same functionality, in both Chrome and Firefox.

# Viewing API in Mobile Applications

If you'd like to view APIs on your mobile applications, it's a little more complicated. You need to use a proxy tool, which is essentially something that will stand between your device and the rest of the internet and collect the traffic, and then display it to you.

So, there's two main proxy tools that I'm aware of, that will work.

The first is Fiddler, which is owned by Telerik, and it's optimized for windows. The best part about Fiddler is that it's free to use.
The other one is Charles Proxy. Charles works on Windows or Mac, but it does require a license fee of about $50.

I use a Mac, so I prefer Charles Proxy, and if you can afford the license fee, or if your company will pay for it, I would definitely recommend Charles Proxy, as a proxy tool.

Just to show the kind of information you can get, out of out a tool such as Charles, this is something I captured from a game I was testing. It shows all the endpoints. We can also access scores and the levels, and it shows the requests, and the response, and all the headers as well. We can go to the sequence, and see what order they were given in. So, this tool is really, really great for discovering about your mobile APIs.

We've discussed a little bit about the basics of APIs, we've looked at APIs in the wild, and we've looked at a few tools that can help you discover more APIs. The thing that is really important to remember, is that APIs are contracts that enable communication between different programs, so, the end result of and API is that communication is happening between two different services, between to different applications, between an application and a service.

# The goal is to have that communication happen, and the goal when you're testing is to make sure that the communication is happening properly.

Add AI to your existing test scripts in minutes!