API Testing Decoded

Roadmap

Block A — API Foundations

A1. What is an API?

An Application Programming Interface is a contract that lets one piece of software ask another piece of software to do something — without knowing how it is done internally. The caller only knows what to send and what it will get back.

Everyday examples you can quote: payment gateways (Razorpay, Stripe), maps (Google Maps), login with Google/GitHub (OAuth), UPI apps talking to bank servers, weather widgets.

A2. API vs Web Service

A3. Usage limits (rate limiting)

Most public APIs cap how many calls a client can make in a time window, and many bill per call. As a tester you should know the limit, test what happens when it is crossed, and make sure your automation suite does not burn through the quota.

• Crossing the limit normally returns 429 Too Many Requests, often with a Retry-After header.
• Headers like X-RateLimit-Limit / X-RateLimit-Remaining tell you where you stand.
• Interview angle: “How would you test rate limiting?” → fire N+1 requests in the window, assert 429, wait, assert recovery.

Block B — HTTP Anatomy

B1. Parts of a request and a response

A response mirrors it: status line (code + reason), headers (Content-Type, Cache-Control, Set-Cookie…), and an optional body. The data you care about is the payload; everything wrapped around it (headers, auth, TLS) is transport.

B2. HTTP methods — the full picture

B3. PUT vs POST — with a real example

Can GET be used to create something? Technically a badly designed server could do it, but it breaks HTTP semantics: GET must be safe, can be cached, prefetched and bookmarked — so creation belongs to POST (or PUT when the client decides the id).

B4. Status code families

B5. Payload size and caching

• GET carries data in the URL, so it is bounded by URL length limits of browsers/servers (commonly a few KB). Never put secrets in a GET URL — it ends up in logs and history.
• POST has no limit in the HTTP spec; real limits come from server config (e.g. body-size limits on gateways). Large payloads cost bandwidth and time — test them for 413 Payload Too Large.
• Caching keeps a copy of a response closer to the client so repeat reads are faster. Driven by Cache-Control, ETag / If-None-Match (→ 304), and Last-Modified. GET responses are cacheable by default; POST generally is not.

Block C — Thinking in REST

C1. What REST really is

REST (Representational State Transfer) is an architectural style, not a protocol. It models everything as a resource identified by a URI, and uses standard HTTP methods to act on it. A service that follows these rules is called RESTful.

C2. The six constraints (say these confidently)

• Client–Server — UI and data storage evolve independently.
• Stateless — every request carries everything needed (token, params). The server keeps no session between calls, so it could restart between two requests and nothing breaks.
• Cacheable — responses declare whether they can be cached.
• Uniform Interface — resources by URI, manipulation via representations, self-descriptive messages.
• Layered System — load balancers, gateways and proxies can sit in between transparently.
• Code on Demand (optional) — server may send executable code, e.g. JavaScript.

C3. Resources, URIs and representations

• A resource is anything worth naming: a user, an order, a PDF, an image, a report.
• A URI identifies it: https://api.shop.com/v1/orders/9812 → scheme / host / version / collection / id.
• A representation is the format it travels in — JSON (most common today), XML, plain text, HTML.
• Content negotiation: client sends Accept: application/json or application/xml; server responds with matching Content-Type.
• Messaging: a request goes out, a response comes back — each message = data + metadata (headers).

Block D — API Testing Strategy

D1. What & why

API testing validates the business layer directly — functionality, reliability, performance and security — by sending requests and checking responses, with no UI involved.

D2. The verification checklist

For every endpoint, walk through this list. It doubles as your interview answer for “What do you check in an API test?”

• Status code — correct for both happy and negative paths.
• Response body data — values match what was sent / what the DB holds.
• Schema — field names, data types, required fields, no extra/missing keys.
• Headers — Content-Type, caching, security headers, CORS.
• Auth — 401 without token, 403 with wrong role, success with right role.
• Error handling — meaningful messages and consistent error format.
• Response time — within the agreed SLA.
• Side effects — the DB row really changed; follow-up GET returns the update.

D3. Designing the test — five-phase lifecycle

Inputs are designed with the same techniques you use in manual testing: equivalence partitioning, boundary values (string length, number ranges, page size), negative data (missing fields, wrong types, invalid enum), and combinations of optional parameters.

D4. A complete test in Playwright + TypeScript

import { test, expect } from '@playwright/test';
 
const BASE = 'https://gorest.co.in/public/v2';
const headers = { Authorization: `Bearer ${process.env.GOREST_TOKEN}` };
 
test('create → read → delete a user', async ({ request }) => {
  // Arrange
  const payload = {
    name: 'AWU Learner',
    email: `awu_${Date.now()}@mail.test`,
    gender: 'female',
    status: 'active',
  };
 
  // Act
  const created = await request.post(`${BASE}/users`, { headers, data: payload });
 
  // Assert
  expect(created.status()).toBe(201);
  const user = await created.json();
  expect(user).toMatchObject(payload);
  expect(typeof user.id).toBe('number');
 
  const fetched = await request.get(`${BASE}/users/${user.id}`, { headers });
  expect(fetched.ok()).toBeTruthy();
 
  // Teardown
  const removed = await request.delete(`${BASE}/users/${user.id}`, { headers });
  expect(removed.status()).toBe(204);
});

Running 1 test using 1 worker
  ✓  user-lifecycle.spec.ts › create → read → delete a user (1.4s)
  1 passed

D5. Types of API testing

D6. Bugs API testing typically finds

• Missing or duplicate functionality; unused flags; “not implemented” endpoints still exposed.
• Poor error handling — 500 instead of 400, stack traces in responses, inconsistent error formats.
• Wrong data types, null where a value is expected, wrong field names vs documentation.
• Security holes — data visible without auth, one user reading another user's record.
• Performance degradation under load; race conditions under concurrent calls.

D7. Real challenges (and how you handle them)

D8. API vs Unit vs UI testing

D9. Tools worth naming

Postman / Newman (manual + CLI runs), Playwright request fixture (TypeScript), REST Assured (Java), SoapUI / ReadyAPI (SOAP & REST), JMeter / k6 (load), Swagger UI (exploration). Mention what you have used and why.

Block E — SOAP Essentials

E1. What SOAP is

SOAP (Simple Object Access Protocol) is an XML-based messaging protocol with strict rules. Platform- and language-independent, it is still common in banking, insurance, telecom and government integrations. It usually travels over HTTP POST, but can also use SMTP or other transports.

E2. Message structure

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
               xmlns:acc="http://bank.example/accounts">
  <soap:Header>
    <acc:AuthToken>abc123</acc:AuthToken>
  </soap:Header>
  <soap:Body>
    <acc:GetBalance>
      <acc:AccountId>AWU-1001</acc:AccountId>
    </acc:GetBalance>
  </soap:Body>
</soap:Envelope>

E3. Rules every SOAP message follows

• Must be well-formed XML using the SOAP Envelope namespace.
• Must not contain a DTD reference or XML processing instructions.
• Envelope namespace changes with the SOAP version (1.1 vs 1.2).

E4. WSDL and the two development approaches

A WSDL (Web Services Description Language) file is the machine-readable contract: operations, input/output messages, data types and endpoint address. Import it into SoapUI and requests are generated for you.

E5. Security, strengths and weak spots

• WS-Security adds message-level security: signatures, encryption, tokens (username, X.509 certificates) — on top of HTTPS transport security.
• Built-in standards for ACID transactions (WS-AtomicTransaction) and guaranteed delivery (WS-ReliableMessaging).
• Weak spots: verbose XML → bigger payloads and slower parsing; no HTTP caching for reads; tooling support varies by language.

Block F — REST or SOAP? Decide & Defend

Interview Questions & Answers