What is an API? REST Basics

Prev Next

Before you open Postman and start clicking Send, it helps to know exactly what you're sending requests to, and why it works the way it does. An API (Application Programming Interface) is simply a contract that lets one program ask another program to do something, without either one needing to know how the other is built internally. When the RecipeBox mobile app shows you a list of dinner recipes, the app isn't reading a database file directly — it sends a request over the network to a RecipeBox server, and the server sends back the data. That request/response conversation, and the rules it follows, is what this whole track is about testing.

The Client-Server Model

Every API interaction has two sides:

Client — whoever is making the request. This could be the RecipeBox mobile app, a website, another server, or — for our purposes — Postman itself acting as a stand-in client.
Server — the program that receives the request, does the work (reading a database, checking permissions, running some logic), and sends back a response.

The client and server don't share memory or call each other's functions directly. They only communicate by exchanging messages over a network protocol — almost always HTTP (HyperText Transfer Protocol) for the kind of APIs you'll test with Postman. As a tester, this separation is exactly what you exploit: you can act as the client yourself, without needing the real mobile app or website at all.

What "REST" Actually Means

REST (REpresentational State Transfer) is a set of conventions for designing APIs over HTTP. It isn't a strict protocol with a rulebook the server must obey — it's a style. Most APIs you'll test, including our RecipeBox example, follow these ideas closely enough that knowing them will make every response you look at make sense immediately:

REST Idea	What It Means in Practice
Resources	Everything the API manages is a "thing" identified by a URL. A single recipe is a resource at `/recipes/42`; the whole collection of recipes is a resource at `/recipes`.
HTTP verbs	The action you want (read, create, update, delete) is expressed as an HTTP method — GET, POST, PUT/PATCH, DELETE — rather than being baked into the URL. The next lesson covers each of these in depth.
Statelessness	Each request must carry everything the server needs to understand it (like an auth token) — the server doesn't remember your previous request. This matters enormously for testing: it means every request can be tested in isolation, and it's why a "session" bug in a REST API is usually a sign something is designed wrong.
JSON as the common format	Request bodies and response bodies are almost always JSON (JavaScript Object Notation) — plain text structured as keys and values. It's the format you'll be reading and asserting against constantly in Postman.

A First Look at a Request and Response

Here's what it actually looks like when a client asks the RecipeBox API for a single recipe by its ID. This is the exact shape of thing you'll be sending from Postman starting in the next few lessons:

// Request
GET https://api.recipebox.example.com/recipes/42

// Response — 200 OK
{
  "id": 42,
  "title": "Paneer Butter Masala",
  "ingredients": ["paneer", "tomato puree", "cream", "butter"],
  "steps": ["Saute the paneer", "Simmer the gravy", "Combine and serve"],
  "photoUri": "https://cdn.recipebox.example.com/img/42.jpg",
  "category": "Dinner",
  "prepMinutes": 20,
  "isPublished": true
}

Notice what's going on: the GET verb says "just give me the data, don't change anything." The URL /recipes/42 names exactly one resource — the recipe with id 42. And the response body is JSON describing that recipe with every field the RecipeBox data model defines: title, ingredients, steps, photoUri, category, prepMinutes, and isPublished.

Note: The RecipeBox API used throughout this track is hypothetical — it doesn't run on this website. Every request and response shown is exactly what you'd see against a real backend built this way, so you can follow along conceptually, or point Postman at any similar public REST API (a couple of free ones are recommended later in this track) and practice the same ideas for real.

Why This Matters Before You Open Postman

As a tester, once you understand "resource + verb + JSON," reading any unfamiliar API's documentation becomes far less intimidating — you're just mapping their resources and verbs onto this same mental model. It also tells you what to actually test:

Does the right resource come back for a given URL?
Does the verb do what it's supposed to (a GET should never change data)?
Is the JSON shaped and typed the way the contract promises — right keys, right types, no missing fields?
Does each request stand on its own, or does something unexpectedly depend on a previous request (a statelessness bug)?

Up next: Head to HTTP Methods to go deep on GET, POST, PUT, PATCH, and DELETE — including idempotency, a concept that comes up constantly once you start writing real API tests.

Prev Next