Overview

At its most basic level, API testing is intended to reveal bugs: inconsistencies or deviations from the expected behavior. Continuous testing is also very important to make sure it continues to work when the public has access to it. The risk of putting a bad, and potentially insecure, product on the market is greater than the cost to test it. (From https://www.soapui.org/learn/functional-testing/api-testing-101.html)

Tools

You're going to either want a tool to help you make requests, or you're going to want to use Firefox, as it has a nice JSON viewer. Just be aware that Firefox can only do GET requests.

About API Calls

API calls have two parts. A REQUEST and a RESPONSE.

The REQUEST is the data you send TO the server.
The RESPONSE is what the server sends back, based on what you sent, and the logic that handles that request.

When you're testing an API call, you're sending a REQUEST, and you're validating that the RESPONSE that the server sends back matches your expectations Most API Calls have a few different parts:

‣

Method

Method is represented by a verb from this list:

GET
POST
PUT
DELETE
PATCH

Sometimes there are others, but rarely. The Method tells the server what it's supposed to do with the URL you provide. Most of the time you'll only ever see GET and POST. The easiest way to think of this is READ and WRITE.

GET is a READ request, as in: "GET me the top 5 posts."
POST is a WRITE request, as in: "POST this data into the database."

‣

URL

URL is straightforward, this is the address that we're going to DO THE THING.

‣

Data

Data comes in two forms, a querystring and a request body.

Querystrings These are part of the URL and show up after a "?". The portion after the "?" is a querystring. Querystrings are represented in key/value pairs. Key comes before the =, value comes after. You can have multiple key/value pairs if you separate them via an "&". Here we're passing along two pieces of information: color=red and style=spicy.

color=red

color=red&style=spicy

Request Body Alternatively, if you're sending a POST request, you can strip the data out of the URL and instead send it as part of a request body. This can come in a few different forms, but you'll either send a block of test, or another set of key/value pairs, depending on what your request is doing.

Working in Postman

Here's what setting up a request looks like in Postman:

By default, we have a GET request, a URL and there's no associated data. (It's GET, so we can't have a body, and there's no query string.)If you hit the Send button, you'll see the response in the box below.

If we move over to a POST request, we'll get the option to add a request body:

Here, we can pick a format for the data. form-data and x-www-form-urlencoded are both key/value pairs. raw lets you put a block of text. binary expects binary data.It's fairly safe to assume that if you're sending a POST request, you'll be expected to use the form-data format.

Getting a Response

Ok, let's get a response.

Here, we've sent a GET request with no data to /programs/sample-program-with-everything. This route gets the PROGRAM with the slug "sample-program-with-everything".The testing rules will be determined by the developer, but here are a few things to watch out for:

This request asks for 1 program. Did we get 1?
This request asks for the program with the slug "sample-program-with-everything". Did we get that program?

Let's look at that.Here's a truncated version of the response:

{
    "ID": 6019947,
    "title": "Title Override!",
    "slug": "sample-program-with-everything",
    "edited_date": 1528998700,
    "save_your_spot_enabled": true,
    "interests": [
        {
            "ID": 130,
            "title": "Beyond Service",
            "slug": "beyond-service"
        }
    ]
}

Reading JSON

There are a few rules when it comes to JSON:

Things in JSON are either wrapped in {} or []

{} means an object. A single thing which has multiple properties.
[] means an array or set of things. Inside an array, you can have 0, 1 or more things.

Things can also be any of the following types:

string (text)
number
boolean (true/false)
array
object

So our response started and ended with {}, so that means we got 1 thing, and it was an object with many properties. Nice!

Each property starts with a Key, then a :, then a value. Keys are ALWAYS strings, which are wrapped in "".Values can have many different formats. Let's look at some:

"ID": 6019947,

Our key is "ID", and our value is a NUMBER. It's not a string, because it isn't wrapped in "".

"slug": "sample-program-with-everything",

Our key is "slug", and our value is "sample-program-with-everything". It's a string, because it's wrapped in "", and hey, it's the right one for the request we sent. Great!

"save_your_spot_enabled": true,

Our key is "save_your_spot_enabled", and the value is true.

This is a boolean or true/false answer. It's a word (true or false), but it isn't wrapped in "".

"interests": [
        {
            "ID": 130,
            "title": "Beyond Service",
            "slug": "beyond-service"
        }
    ]

Our key is "interests", and our value is wrapped in [], which means it's a set of things. in this instance, it's a set of objects, but it could easily be a set of strings or numbers, or anything else.

The Result

Did we get what we wanted? Well yes. We wanted 1 thing, we got 1 thing. We wanted that thing to have the slug "sample-program-with-everything", and it did.

Adding Data

Let's test the following URL:

http://cms.rusticpathways.com/wp-json/rusticpathways/v1/programs/?country=china

Our URL now is "/programs/". This is an index route, which will, by default, list all programs. We've added some data to narrow down the results.?country=chinaSo this says "only show me programs where country = china.

What are we looking for here?

It's an index, so we're likely looking for an ARRAY of things (so our response should start with a []).
We're going to look through each program and ensure that within the Country properties, we see "china" at least once.