API Testing Fundamentals

What Is an API? #

An API (Application Programming Interface) is a contract between two software systems. It defines how one system can request data or actions from another and what format the response will take. Think of it as a waiter in a restaurant: you (the client) place an order, the waiter (the API) carries it to the kitchen (the server), and brings back your food (the response).

In modern software development, APIs are everywhere. When you check the weather on your phone, the app sends an API request to a weather service. When you log in with Google on a third-party site, OAuth APIs handle the authentication. When your bank app shows your balance, it calls the bank’s backend API.

APIs in Modern Architecture #

Most modern applications follow a client-server architecture where the frontend (web or mobile app) communicates with the backend through APIs. This separation has become the standard because it allows:

• Multiple clients to use the same backend (web, iOS, Android, partner integrations)
• Independent development where frontend and backend teams work in parallel
• Scalability since each layer can be scaled independently
• Reusability where the same API serves different products and features

A typical e-commerce application might have dozens of APIs: one for user authentication, another for product catalog, one for the shopping cart, another for payments, and so on.

Why API Testing Matters #

The Testing Pyramid Perspective #

The testing pyramid, introduced by Mike Cohn, suggests that your test suite should have many unit tests at the base, fewer integration/API tests in the middle, and even fewer UI tests at the top. API tests occupy that crucial middle layer because they:

1. Run faster than UI tests — no browser rendering, no page loads, no waiting for animations
2. Are more stable than UI tests — no flaky element selectors or timing issues
3. Cover more logic — a single API can serve multiple UI screens
4. Catch integration bugs — they verify how different services communicate

Real-World Impact #

Consider this scenario: your e-commerce site has a checkout flow. A UI test might take 30-60 seconds to fill in forms, click buttons, and verify the result. The equivalent API test — sending a POST request to /api/orders with the order payload — takes under 1 second and tests the same business logic.

At Google (Waze), API testing was critical because the mobile app depended on dozens of backend services. A broken API could affect 150+ million users. Catching issues at the API layer before they reach the UI saved enormous amounts of debugging time.

What API Testing Covers #

API testing validates several aspects of the backend:

Core Concepts #

Request and Response #

Every API interaction follows a request-response pattern:

Request consists of:

• URL/Endpoint — where to send the request (e.g., https://api.example.com/users)
• Method — what action to take (GET, POST, PUT, DELETE)
• Headers — metadata like authentication tokens, content type
• Body — data payload (for POST/PUT requests)

Response consists of:

• Status code — numeric indicator of success or failure (200, 404, 500)
• Headers — metadata like content type, rate limit info
• Body — the actual data returned (usually JSON or XML)

Request:
GET /api/users/42 HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiJ9...
Accept: application/json

Response:
HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": 42,
  "name": "Alice Johnson",
  "email": "alice@example.com",
  "role": "admin"
}

Types of APIs #

While this module focuses primarily on REST APIs (the most common type), you should be aware of the landscape:

• REST — resource-based, uses HTTP methods, JSON responses (most common)
• GraphQL — query language, client specifies exactly what data it needs
• gRPC — high-performance, uses Protocol Buffers, common in microservices
• SOAP — XML-based, strict contract, common in enterprise/legacy systems
• WebSocket — bidirectional, real-time communication

We cover each of these in dedicated lessons later in this module.

API Testing Approaches #

Manual API Testing #

When starting out, manual testing with tools like Postman or cURL gives you immediate feedback and helps you understand how APIs work. You’ll send requests, inspect responses, and verify behavior interactively. This is excellent for:

• Exploratory testing of new endpoints
• Debugging specific issues
• Learning how an API behaves before writing automated tests
• Quick verification during development

Automated API Testing #

As your test suite grows, automation becomes essential. Automated API tests can:

• Run in CI/CD pipelines on every code change
• Cover hundreds of scenarios in seconds
• Detect regressions immediately
• Serve as living documentation of expected behavior

Common automation tools include REST Assured (Java), pytest + requests (Python), Supertest (Node.js), and Postman/Newman for collection-based testing.

Contract Testing #

Contract testing verifies that an API meets the agreement (contract) between consumer and provider. This is especially important in microservices architectures where many services depend on each other. Tools like Pact help ensure that changes to one service don’t break others.

Building Your First API Test Plan #

When approaching a new API for testing, follow this systematic process:

Step 1: Understand the API Documentation #

Read the API specification (Swagger/OpenAPI, README, or wiki). Note:

• Available endpoints and their purposes
• Required and optional parameters
• Authentication requirements
• Rate limits and constraints

Step 2: Identify Test Scenarios #

For each endpoint, create test scenarios covering:

Happy path:

• Valid requests with all required fields
• Valid requests with optional fields included
• Different valid values for each parameter

Negative testing:

• Missing required fields
• Invalid data types (string where number expected)
• Boundary values (empty strings, maximum lengths, zero, negative numbers)
• Invalid authentication

Edge cases:

• Special characters in strings (Unicode, emojis, HTML tags)
• Very large payloads
• Concurrent requests to the same resource
• Requests with extra/unknown fields

Step 3: Define Expected Results #

For each scenario, document what the API should return:

• Expected status code
• Expected response body structure
• Expected error messages for negative cases
• Expected side effects (database changes, events triggered)

Step 4: Prioritize and Execute #

Not all tests are equally important. Prioritize:

1. Authentication and authorization
2. Core business logic (CRUD operations)
3. Input validation and error handling
4. Edge cases and boundary conditions
5. Performance under load

Hands-On Exercise #

Using any REST API (we recommend JSONPlaceholder — a free fake API for testing), complete these tasks:

1. Send a GET request to https://jsonplaceholder.typicode.com/posts/1 and identify all fields in the response
2. Send a POST request to https://jsonplaceholder.typicode.com/posts with a JSON body containing title, body, and userId — note the status code
3. Send a GET request to https://jsonplaceholder.typicode.com/posts/9999 (non-existent) — what status code do you get?
4. Document your findings in a simple test report: endpoint, method, input, expected result, actual result, pass/fail

You can use your browser’s developer tools (Network tab), cURL from the terminal, or download Postman (covered in Lesson 6.4).

Key Takeaways #

• APIs are the communication layer between software systems and are critical to modern application architecture
• API testing sits in the middle of the testing pyramid, offering a balance of speed, stability, and coverage
• Every API interaction follows a request-response pattern with methods, headers, status codes, and body
• A thorough API test plan covers happy paths, negative scenarios, edge cases, and security
• Start with manual testing to build understanding, then move to automation for regression coverage