What Is an API and How APIs Work

Every modern app you use is held together by APIs. Open a banking app and it calls an API to fetch your balance. Tap Pay and another API charges your card. Even your CI pipeline calls APIs to deploy code, post messages to Slack, and run automated tests. As a QA engineer, you'll spend a meaningful chunk of your career testing these invisible interfaces — and your tests will run faster, find more bugs, and break less often than the equivalent UI tests. This lesson explains what an API actually is, how it works under the hood, and why APIs sit at the heart of modern QA.

What "API" really means

API stands for Application Programming Interface. Strip the jargon and an API is just a contract: "Send me data in this shape, and I will send back data in that shape." It's how one piece of software talks to another without either side knowing the other's internals.

The classic analogy is a restaurant. You sit at a table and look at the menu — that's the API documentation, listing what you can order and what you'll get back. You give the waiter your order — that's the API request. The waiter walks to the kitchen, where chefs cook your meal — that's the server processing. The waiter brings your food back — that's the API response. You don't know how the kitchen works, what brand of oven they use, or where they buy their basil. You just need the menu and someone to take orders.

The client–server model

Every API call has two roles:

• The client — the thing making the request. A mobile app, a browser, a Postman tab, a test script, another microservice.
• The server — the thing that owns the data and decides what to return. A backend service, often hosted somewhere like AWS, behind a URL like api.example.com.

The client sends a request. The server processes it. The server sends back a response. That cycle is the only thing happening on the wire. Everything you'll learn in this course — REST, GraphQL, auth, performance — is just rules and patterns layered on top of that simple loop.

Where APIs show up in QA work

A few real examples that turn up across QA jobs:

• Frontend → backend. A React app calls GET /api/users/123 to load a profile page. The UI test fails — half the time it's actually the API.
• Mobile → payment provider. Tapping Pay sends a POST to Stripe. You'll test the integration without ever opening the iOS simulator.
• CI/CD → deployment platform. Your pipeline calls Vercel, AWS, or Kubernetes APIs to ship code. Smoke tests then call your service's API to verify the release worked.
• Test tools → app under test. Postman, REST clients, and code-based test frameworks send requests and assert on responses. That is API testing.
• Service → service. Inside a microservices architecture, the order service calls the inventory service which calls the warehouse service. Each hop is an API call.

Types of APIs you'll meet

Not every API is the same. A quick taxonomy:

• REST — the most common style for web APIs. Resources at URLs, standard HTTP methods, JSON bodies. This course focuses here.
• GraphQL — a query language where the client picks exactly which fields it wants. Single endpoint, flexible queries. Covered in Chapter 6.
• SOAP — older, XML-based, heavy on schemas. You'll meet it in banking, government, and long-lived enterprise systems.
• gRPC — high-performance, binary protocol used between microservices.
• WebSocket — bidirectional, real-time. Chat apps, live dashboards, multiplayer games.

You don't need to be an expert in all five. Get fluent in REST, learn enough GraphQL to test it, and recognise the others when they appear.

A real call with curl

curl is a command-line tool that ships on macOS, Linux, and modern Windows. It's the universal way to make an HTTP request without any app, IDE, or framework involved.

curl https://jsonplaceholder.typicode.com/users/1

One line sends a GET request and prints the response body — a JSON object describing user 1. Whatever client you eventually use (Postman, Insomnia, or an automated test), it's doing the same thing under the hood.

The request–response cycle, visualised

Five steps, repeated billions of times a day across the internet. Internalise this loop — every API test you ever write is asserting on one or more iterations of it.

Why APIs matter for QA

API testing has earned its place at the centre of modern QA for concrete reasons:

• Faster — no browser to launch, no DOM to render. A 200ms API test can replace a 20s UI test.
• More reliable — APIs change less than UIs. A button moving to the right side of the page breaks every Selenium test that targeted it; the underlying API is unaffected.
• Tests business logic directly — discount engines, tax rules, postcode validation. The logic lives at the API level, so test it there.
• Earlier in the pipeline — you don't need a finished UI to test the API. Shift-left at its most concrete.
• Easier to cover edge cases — concurrent requests, malformed input, expired tokens. Trivial via API, awkward via UI.

UI tests still matter — visual rendering, navigation, accessibility — but a healthy test suite leans on the API layer for the bulk of behavioural coverage. The next chapter formalises that intuition into the testing pyramid.

⚠️ Common mistakes

• Treating "the API" as a single thing. Every endpoint is an independent contract — GET /users may be rock solid while POST /orders is broken. Test each on its own merits.
• Confusing client with server. Postman, curl, and your test code are all clients. The bug usually lives on the server, but a client misconfiguring headers or auth can produce errors that look like server problems.
• Assuming HTTPS implies REST. HTTPS is just the transport (encrypted HTTP). REST, GraphQL, and SOAP all run over HTTPS. The protocol underneath doesn't tell you the API style on top.

🎯 Practice task

Get hands-on with a real API — 15-20 minutes, no setup beyond a terminal.

1. Run curl https://jsonplaceholder.typicode.com/users. Read the response — a JSON array of fake users.
2. Now run curl https://jsonplaceholder.typicode.com/users/1. Notice the URL pattern (/users/{id}) and how the response shape changed from an array to a single object.
3. Open a real app you use — a banking app, a food-delivery site, a fitness tracker. In Chrome, open DevTools → Network. Click around and watch the API calls fly past. Pick one and read its method, URL, and response.
4. List five APIs your daily workflow depends on (login, email, calendar, music, navigation). For each, jot down what data you think the client sends and what the server returns.
5. Stretch: open the API Testing Concepts cheat sheet on qa.codes to preview terms you'll meet later in this course. Don't worry about specifics — just notice every example is a variant of the request–response loop you just made with curl.

You now know what an API is and how a single call works. The next lesson zooms out to the architectural style that shapes most of the APIs you'll meet: REST.