Skip to content

Step 1 of 6 · about 35 min

HTTP and JSON, the practical version

APIs are how the front end you already know talks to the back end you have not met. This is where your JavaScript background quietly pays off, because JSON is basically a JavaScript object that put on a coat to go outside.

The parts you need. Methods say what you want to do: GET reads, POST creates, PUT updates, DELETE removes. Status codes say how it went: 200 means fine, 400 means you sent something wrong, 401 means you are not allowed in, 404 means it is not there, 500 means the server itself broke. REST is just the convention that ties tidy URLs to those methods.

Here is a real response, trimmed, so you can see the shape you will be asserting against. This is what the Rick and Morty API returns for character 1.

Response body, character 1
{
"id": 1,
"name": "Rick Sanchez",
"status": "Alive",
"species": "Human",
"origin": { "name": "Earth (C-137)" },
"episode": [
  "https://rickandmortyapi.com/api/episode/1",
  "https://rickandmortyapi.com/api/episode/2"
]
}

Read it as data with a shape. Some fields are strings, origin is a nested object with its own name, and episode is an array. An assertion later will reach into exactly one of these, so knowing the shape is the whole game.

Try it: name the parts

For the response above, answer three things in a note. Which field would you check to confirm the character is alive? How would you read the origin's name in JavaScript, starting from a variable called body? And how many episodes are in that array? If you wrote body.origin.name and 2, you are already reading responses the way the tests will.

Why

Testing at the API level finds problems before they reach a screen, and it is faster and steadier than clicking. It is also where a great deal of QA automation actually spends its time.