HTTP Headers for API Testing: Content-Type, Accept, Caching and ETag

Headers are the small key-value lines that travel with every request and response. They decide whether the server reads your body as JSON, who you are, which format comes back, whether a response may be cached, and whether two people editing the same record overwrite each other. Many testers ignore headers and miss whole categories of bugs. In this lesson you will learn the headers that matter for API testing, with real-life examples and live calls.

What Are HTTP Headers? (The Parcel Label Example)

Headers are written as Name: value, one per line. Names are case-insensitive: content-type and Content-Type are the same header (Playwright returns all names in lower case).

Request Headers Every Tester Should Know

Response Headers Every Tester Should Check

See them live. Press Send and look at link and x-total-count in the output:

curl -i \
  "https://sqatools.in/wp-json/sqa-api/v1/users?per_page=2"

Content Negotiation: Content-Type vs Accept

These two are confused all the time:

• Content-Type describes the body being sent (in a request: what you send; in a response: what the server sends).
• Accept is a request header saying what format you would like back.

curl -i \
  -H "Accept: text/csv" \
  "https://sqatools.in/wp-json/sqa-api/v1/users/1"

The practice API answers 406 because it can return only JSON or XML. Change Accept to application/xml and you get XML.

Caching Headers: Cache-Control, ETag and 304

Caching saves bandwidth and makes apps fast. A product image or a catalogue page that hasn’t changed doesn’t need to be downloaded again.

Cache-Control

• max-age=3600: the response can be reused for 1 hour.
• no-cache: may be stored, but must be revalidated with the server before use.
• no-store: never store it. Required for sensitive data such as bank balances, OTPs and personal details.
• private vs public: whether shared caches (CDN, proxies) may store it.

ETag and conditional requests

An ETag is a fingerprint of the current version of a resource. The client stores it and next time asks: “send it only if it changed” using If-None-Match.

1. GET /products/101 → 200, ETag: "c2aee9e25c4daa9445361e1bb4a749f7".
2. GET /products/101 with If-None-Match: "c2aee9e25c4daa9445361e1bb4a749f7" → 304 Not Modified, empty body.

curl -i \
  -H "If-None-Match: \"c2aee9e25c4daa9445361e1bb4a749f7\"" \
  "https://sqatools.in/wp-json/sqa-api/v1/products/101"

If the browser shows 200 instead of 304 here, the product data has changed since this lesson was written; copy the new ETag from a normal GET and try again.

Optimistic Locking with If-Match (Prevent Lost Updates)

# 1. Create an object, note ETag "v1"
curl -i -X PUT "https://sqatools.in/wp-json/sqa-api/v1/objects/ticket-500" \
  -H "Content-Type: application/json" -d '{"name":"Ticket 500","data":{"priority":"low"}}'

# 2. Update with the current version: 200, ETag becomes "v2"
curl -i -X PATCH ".../objects/ticket-500" -H "If-Match: \"v1\"" \
  -H "Content-Type: application/json" -d '{"data":{"priority":"high"}}'

# 3. Update again with the OLD version: 412 Precondition Failed
curl -i -X PATCH ".../objects/ticket-500" -H "If-Match: \"v1\"" \
  -H "Content-Type: application/json" -d '{"data":{"status":"closed"}}'

The practice API’s 412 message: If-Match “v1” does not match the current version “v2”. Someone changed the object; GET it again.

Security Headers to Verify

CORS is covered in detail in HTTPS, Cookies and CORS.

Testing Headers with Playwright

import { test, expect } from '@playwright/test';

const BASE = 'https://sqatools.in/wp-json/sqa-api/v1';

test('JSON content type and no caching of user data', async ({ request }) => {
  const res = await request.get(`${BASE}/users/1`);
  const h = res.headers();                       // all names are lower case
  expect(h['content-type']).toContain('application/json');
  expect(h['cache-control']).toContain('no-store');
  expect(h['x-content-type-options']).toBe('nosniff');
});

test('ETag + If-None-Match gives 304', async ({ request }) => {
  const first = await request.get(`${BASE}/products/101`);
  const etag = first.headers()['etag'];
  expect(etag).toBeTruthy();

  const second = await request.get(`${BASE}/products/101`, {
    headers: { 'If-None-Match': etag },
  });
  expect(second.status()).toBe(304);
  expect((await second.body()).length).toBe(0);
});

test('stale If-Match is rejected with 412', async ({ request }) => {
  const url = `${BASE}/objects/lock-${Date.now()}`;
  await request.put(url, { data: { name: 'Ticket', data: { priority: 'low' }, ttl: 60 } });  // v1
  await request.patch(url, { data: { data: { priority: 'high' } }, headers: { 'If-Match': '"v1"' } }); // v2
  const stale = await request.patch(url, { data: { data: { status: 'closed' } }, headers: { 'If-Match': '"v1"' } });
  expect(stale.status()).toBe(412);
});

test('pagination headers', async ({ request }) => {
  const res = await request.get(`${BASE}/users?per_page=5`);
  expect(res.headers()['x-total-count']).toBe('12');
  expect(res.headers()['link']).toContain('rel="next"');
});

Header Testing Checklist

• Correct Content-Type on every response, including errors.
• Missing/wrong Content-Type on requests gives 415, not 500.
• Unsupported Accept gives 406.
• Location on 201; Allow on 405; WWW-Authenticate on 401; Retry-After on 429/503.
• Personal data is never publicly cacheable.
• ETag changes when the resource changes; 304 when it doesn’t; 412 on stale If-Match.
• No version-revealing headers; security headers present.
• Header names treated case-insensitively.

Interview Questions: HTTP Headers

HTTP Status Codes: Complete List with API Testing Examples

The status code is the first thing every client reads in an API response, and the first thing a tester should assert. A login API that answers 200 OK with “invalid password” in the body, or a typo in a search that crashes with 500, are real bugs that ship to production every day. This lesson is your complete HTTP status codes reference for API testing: every code you will meet, what it means in real life, and how to test it on live endpoints.

The 5 Classes of HTTP Status Codes

Try Any Status Code Live

The practice API has a helper endpoint that returns whatever status you ask for: GET /status/{code}. Use it to check how your client, Postman tests or Playwright framework handle each code. Here is a 503 with a Retry-After header:

curl -i \
  "https://sqatools.in/wp-json/sqa-api/v1/status/503"

Edit the URL to /status/201, /status/204, /status/409 and more. An invalid code such as /status/700 returns 400.

2xx Success Codes

200 vs 201 vs 204

• Create an order → 201 Created (not 200). The practice API’s POST /objects follows this rule.
• Fetch an order → 200 OK.
• Delete an order → 204 No Content.

3xx Redirection Codes

Practice: GET /redirect returns 302; POST /redirect?status=307 keeps the POST; POST /redirect?status=303 switches to GET. Conditional GET: request /products/101 with If-None-Match set to its ETag and you get 304. Details in HTTP headers and caching.

4xx Client Error Codes

The Confusing Pairs (Interview Favourites)

401 Unauthorized vs 403 Forbidden

A 401 should include a WWW-Authenticate header. Try it on the Basic auth endpoint with no credentials:

curl -i \
  "https://sqatools.in/wp-json/sqa-api/v1/basic/profile"

On the practice API, a missing API key gives 401, a wrong API key gives 403, and a viewer token trying to create gives 403.

400 Bad Request vs 422 Unprocessable Content

• 400: the server can’t even read it. Broken JSON, empty body, a JSON array instead of an object, text where a number is required in the URL.
• 422: the JSON is valid, but the values break business rules: invalid email, age out of range, unknown enum value.

curl -i \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"name":"A","email":"not-an-email","age":17}' \
  "https://sqatools.in/wp-json/sqa-api/v1/validate/user"

The response lists every failing field at once, which is the behaviour you want from a well-designed API.

404 Not Found vs 403 for Hidden Resources

For security, many APIs return 404 instead of 403 when you request another user’s private resource, so attackers can’t even learn that it exists. Both are acceptable; returning the data is not.

409 Conflict vs 412 Precondition Failed

409 is a business conflict (duplicate email). 412 is a technical version conflict when you send If-Match with an old ETag (optimistic locking). The practice API’s /objects supports both scenarios.

5xx Server Error Codes

Status Codes for Each HTTP Method

Automating Status Code Checks with Playwright

A data-driven test checks many codes in a few lines. Use maxRedirects: 0 to assert a redirect itself instead of following it.

import { test, expect } from '@playwright/test';

const BASE = 'https://sqatools.in/wp-json/sqa-api/v1';

const cases = [
  { name: 'existing user',      path: '/users/1',     expected: 200 },
  { name: 'missing user',       path: '/users/999',   expected: 404 },
  { name: 'non-numeric id',     path: '/users/abc',   expected: 400 },
  { name: 'page size too big',  path: '/users?per_page=51', expected: 400 },
  { name: 'no credentials',     path: '/basic/profile',     expected: 401 },
  { name: 'service down',       path: '/status/503',  expected: 503 },
];

for (const c of cases) {
  test(`GET ${c.path} -> ${c.expected} (${c.name})`, async ({ request }) => {
    const res = await request.get(`${BASE}${c.path}`);
    expect(res.status()).toBe(c.expected);
  });
}

test('redirect is 302 when not followed', async ({ request }) => {
  const res = await request.get(`${BASE}/redirect`, { maxRedirects: 0 });
  expect(res.status()).toBe(302);
  expect(res.headers()['location']).toBeTruthy();
});

test('503 tells the client when to retry', async ({ request }) => {
  const res = await request.get(`${BASE}/status/503`);
  expect(res.headers()['retry-after']).toBe('10');
});

Note: res.ok() is true only for 200-299. Playwright does not throw on 4xx/5xx by default, which is what you want for negative tests.

How to Report a Wrong Status Code

A good bug title: “POST /orders returns 500 instead of 422 when quantity is negative”. Include the full request (cURL), the actual and expected status, the response body, the trace or request id header and the environment. Developers fix these fast when they can replay the request.

Interview Questions: HTTP Status Codes

HTTP Methods Explained: GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS

HTTP methods are the verbs of an API: they tell the server what you want to do with a resource. Mix them up and you get bugs like a “GET” that deletes data or a retry that charges a customer twice. In this lesson you will learn all seven methods testers use, the difference between PUT and PATCH, what “safe” and “idempotent” really mean, and you will run each method on a live object you create yourself.

Real-Life Example: Managing Your Address Book in a Shopping App

This mapping of methods to actions is called CRUD: Create (POST), Read (GET), Update (PUT/PATCH) and Delete (DELETE).

All HTTP Methods at a Glance

Two rarer methods: TRACE (echoes the request, should be disabled in production for security) and CONNECT (used by proxies for HTTPS tunnels).

GET: Read Data

GET retrieves data and must never change anything on the server. Parameters go in the URL path or query string.

curl -i \
  "https://sqatools.in/wp-json/sqa-api/v1/users?role=admin&sort=age&order=desc"

Test ideas: correct data and count; filters and sorting; 404 for a missing id; 400 for an invalid id (/users/abc); calling it twice changes nothing; sensitive data not exposed; response time.

POST: Create a New Resource

POST sends data in the body; the server decides the new id. A correct create returns 201 Created and a Location header.

curl -i \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"name":"Office address","data":{"city":"Pune","pin":"411001"},"ttl":300}' \
  "https://sqatools.in/wp-json/sqa-api/v1/objects"

Test ideas: 201 + Location; body echoes what you sent; required fields missing → 422; extra unknown fields; client trying to set the id (the practice API rejects it with 422); duplicate submission.

PUT: Replace (or Create at a Known URL)

PUT sends the complete new version of a resource to its URL. Any field you leave out is removed or reset. If the resource does not exist, many APIs create it (called an upsert).

On the practice API you choose the id. The first PUT returns 201 Created; repeating the same PUT returns 200 OK with the same content, which is what idempotent means.

curl -i \
  -X PUT \
  -H "Content-Type: application/json" \
  -d '{"name":"Home address","data":{"city":"Mumbai","pin":"400001"},"ttl":300}' \
  "https://sqatools.in/wp-json/sqa-api/v1/objects/my-address-01"

Test ideas: full replacement (omitted fields disappear); name missing → 422 (PUT needs the full representation); id in body different from id in URL → 422; repeat the call → same state; version increments.

PATCH: Update Only Some Fields

PATCH sends only the fields that change. The practice API uses JSON Merge Patch rules: fields you send are merged in, and a field set to null is removed.

curl -i -X PATCH "https://sqatools.in/wp-json/sqa-api/v1/objects/my-address-01" \
  -H "Content-Type: application/json" \
  -d '{"data":{"pin":"400002"}}'

Result: city stays “Mumbai”, pin becomes “400002”, version goes up by 1, and the ETag changes from "v1" to "v2".

Test ideas: only sent fields change; null removes a key; empty body {} → 422 “nothing to update”; PATCH on a missing id → 404; read-only fields (id, created_at) cannot be patched.

PUT vs PATCH: The Most Asked Interview Question

Example: the stored object is {"name":"Home","data":{"city":"Mumbai","pin":"400001"}}.

• PUT {"name":"Home","data":{"pin":"400002"}} → city is gone.
• PATCH {"data":{"pin":"400002"}} → city is kept.

DELETE: Remove a Resource

DELETE removes the resource. The common success code is 204 No Content (empty body).

curl -i \
  -X DELETE \
  "https://sqatools.in/wp-json/sqa-api/v1/objects/my-address-01"

Press Send twice. The first call returns 204, the second 404. Is that still idempotent? Yes: idempotency is about the server state (the object is gone either way), not about the status code.

Test ideas: 204 then GET returns 404; deleting twice; deleting without permission → 403; deleting a resource that has children (an order with payments); soft delete vs hard delete; DELETE on read-only resources → 405 (try DELETE /products/101).

HEAD and OPTIONS: The Methods Testers Forget

HEAD

Returns exactly the headers a GET would return, but no body. Used to check if a resource exists, its size (Content-Length) or its version (ETag) without downloading it, for example before downloading a 2 GB file.

curl -I \
  "https://sqatools.in/wp-json/sqa-api/v1/users/1"

OPTIONS

Asks which methods are allowed. The answer comes in the Allow header. Browsers also send OPTIONS automatically as a CORS pre-flight before cross-origin PUT/DELETE requests.

curl -i \
  -X OPTIONS \
  "https://sqatools.in/wp-json/sqa-api/v1/users"

405 Method Not Allowed

When you use a method an endpoint does not support, the correct answer is 405 with an Allow header listing valid methods. On the practice API, POST /users returns: “This endpoint supports GET, HEAD only.” A 404 or 500 here would be a bug.

Safe vs Idempotent, Explained Simply

• Safe = read-only. Calling it does not change data. (GET, HEAD, OPTIONS)
• Idempotent = calling it once or 10 times leaves the server in the same state. (All safe methods + PUT + DELETE)

Why testers care: networks fail, and clients and gateways retry. Retrying idempotent requests is safe; retrying POST without an idempotency key can create duplicates.

All Methods in One Playwright Test

import { test, expect } from '@playwright/test';

const BASE = 'https://sqatools.in/wp-json/sqa-api/v1';

test('HTTP methods on one object', async ({ request }) => {
  const id = `pw-${Date.now()}`;
  const url = `${BASE}/objects/${id}`;

  // PUT creates (201), PUT again is idempotent (200, same data)
  const body = { name: 'Home', data: { city: 'Mumbai', pin: '400001' }, ttl: 120 };
  expect((await request.put(url, { data: body })).status()).toBe(201);
  expect((await request.put(url, { data: body })).status()).toBe(200);

  // PATCH changes one field and keeps the rest
  const patched = await (await request.patch(url, { data: { data: { pin: '400002' } } })).json();
  expect(patched.data).toEqual({ city: 'Mumbai', pin: '400002' });

  // HEAD: headers only, no body
  const head = await request.head(url);
  expect(head.status()).toBe(200);
  expect((await head.body()).length).toBe(0);

  // DELETE twice: 204 then 404 (state is the same: gone)
  expect((await request.delete(url)).status()).toBe(204);
  expect((await request.delete(url)).status()).toBe(404);
});

test('unsupported method returns 405 with Allow header', async ({ request }) => {
  const res = await request.post(`${BASE}/users`, { data: {} });
  expect(res.status()).toBe(405);
  expect(res.headers()['allow']).toBeTruthy();
});

Interview Questions: HTTP Methods

Types of API Testing: 12 Types Explained with Real Examples

“API testing” is not one activity. A payment API that returns the right amount can still leak card data, crash at 2,000 users per second, or break the Android app because a field was renamed. In this lesson you will learn the 12 types of API testing used in real projects, each with a real-life scenario, a concrete test on the free SQA Tools practice API and the tools teams use for it.

The Real-Life Scenario We Will Use

The practice API mirrors this store: it has users, products, orders, login tokens, validation rules and rate limits, so every type below has a test you can actually run.

1. Smoke Testing

A tiny, fast set of checks that answers one question: is the API up and basically working after a deployment? If smoke fails, there is no point running the other 2,000 tests.

Real example: right after a release at 2 AM, a pipeline calls the health endpoint and one key read endpoint.

curl -i \
  "https://sqatools.in/wp-json/sqa-api/v1/health"

Checks: 200 status, "status": "ok", response time under 1 second. Tools: Postman monitor, Playwright test tagged @smoke, uptime monitors.

2. Functional Testing

Verifies that each endpoint does what the requirement says, with valid input. This is the bulk of API testing.

Real example: requirement “Filter products by category” means GET /products?category=books must return only books.

curl -i \
  "https://sqatools.in/wp-json/sqa-api/v1/products?category=books"

Checks: status 200; every item has category = "books"; count matches; prices are numbers; sorting works as documented.

3. Negative and Validation Testing

Sends invalid, missing, out-of-range or wrongly typed data and checks the API rejects it gracefully: correct 4xx code, useful message, no crash, no data saved.

Real example: a signup form sends an empty body. The API should list every missing field in one response, not fail with 500.

curl -i \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{}' \
  "https://sqatools.in/wp-json/sqa-api/v1/validate/user"

The practice API answers 422 with three field errors (name, email, age). Other negative cases: age as a string, age 17 and 101 (boundaries), invalid email, malformed JSON (400), wrong Content-Type (415), body over 10 KB (413).

4. Integration Testing

Checks that two or more components work together correctly: API + database, service A + service B, your app + a third-party API.

Real example: when an order is placed, the order service must call the inventory service so stock drops by the ordered quantity. Test: read stock, place order, read stock again.

On the practice API, the nested resource GET /users/1/orders checks that user and order data are correctly linked: every order returned must have user_id = 1.

5. End-to-End (Workflow) Testing

Chains several API calls in the order a real user would make them, passing data from one response into the next request.

Real example: Login → search product → add to cart → place order → pay → check order status “paid”.

import { test, expect } from '@playwright/test';
const BASE = 'https://sqatools.in/wp-json/sqa-api/v1';

test('workflow: create, update, verify, delete', async ({ request }) => {
  const created = await (await request.post(`${BASE}/objects`, {
    data: { name: 'Cart #1', data: { items: 1 }, ttl: 120 },
  })).json();

  const patched = await request.patch(`${BASE}/objects/${created.id}`, { data: { data: { items: 3 } } });
  expect(patched.status()).toBe(200);
  expect((await patched.json()).version).toBe(2);

  const read = await (await request.get(`${BASE}/objects/${created.id}`)).json();
  expect(read.data.items).toBe(3);

  expect((await request.delete(`${BASE}/objects/${created.id}`)).status()).toBe(204);
  expect((await request.get(`${BASE}/objects/${created.id}`)).status()).toBe(404);
});

6. Contract Testing

Verifies that the API’s structure (field names, data types, required fields, status codes) matches the agreed contract, so consumers like the mobile app do not break.

Real example: a backend developer renames price to amount. All functional tests still pass on the backend, but the Android app shows “Rs null”. A contract test against the JSON Schema catches it in CI before release.

The practice API publishes its schema: GET /schema/user returns a JSON Schema with "additionalProperties": false. Tools: JSON Schema validators (Ajv, Zod), Pact for consumer-driven contracts, OpenAPI diff tools.

7. Security Testing

Checks authentication, authorization, data exposure, injection and abuse protection. The OWASP API Security Top 10 is the standard checklist.

curl -i \
  "https://sqatools.in/wp-json/sqa-api/v1/basic/profile"

8. Performance and Load Testing

Measures response time and throughput under normal and peak traffic. Related types:

• Load testing: expected peak, e.g. 500 requests/second during a sale.
• Stress testing: increase until it breaks, to find the limit and how it fails.
• Spike testing: sudden jump, e.g. traffic x10 when a flash sale opens at 12:00.
• Soak (endurance) testing: steady load for hours to find memory leaks.

Real example: Big Billion Day style sales. The product API must stay under 300 ms at the 95th percentile with 5x normal traffic.

The practice API has /delay/{seconds} to simulate slow responses and /rate-limit, which returns 429 Too Many Requests with Retry-After on the 6th call in a minute. Tools: k6, JMeter, Gatling, Artillery; Playwright for simple SLA assertions.

9. Reliability and Resilience Testing

Checks how the API and its clients behave when things go wrong: timeouts, slow dependencies, 503 responses, retries and circuit breakers.

Real example: the SMS provider is down. Does signup still complete (OTP queued for retry) or does the whole API return 500?

Practise with GET /status/503 (returns Retry-After: 10) and GET /delay/5 with a 2-second client timeout. Your client should give up cleanly and retry with back-off.

10. Regression Testing

Re-runs existing API tests after every code change to make sure nothing that used to work is now broken. This is where automation pays off: 1,000 API tests can run in a few minutes on every pull request in GitHub Actions or Jenkins.

Real example: a developer optimises the pricing query. The regression suite catches that orders with a coupon now return total 0.

11. Fuzz Testing

Sends large volumes of random, malformed or unexpected input to discover crashes and unhandled errors. Any 5xx during fuzzing is a bug.

Real example: sending a 1 MB string, emojis, null bytes, nested JSON 1,000 levels deep or numbers like 1e309 to the product search API. Tools: RESTler, Schemathesis (generates tests from OpenAPI), Burp Suite Intruder.

12. Compatibility and Versioning Testing

Ensures new API versions do not break existing clients and that old versions keep working until they are retired.

Real example: 30% of users never update the app. When /v2/orders launches, /v1/orders must keep the old response shape. Testers run the v1 suite against the new build and check deprecation headers.

Summary Table: Types of API Testing

Interview Questions: Types of API Testing

REST vs SOAP vs GraphQL: Differences Every Tester Should Know

“What is the difference between REST and SOAP?” has been asked in almost every API testing interview for over a decade, and GraphQL is now added to it. In this lesson you will see one real requirement, “get the balance and last two transactions of a bank customer”, built three ways, so the differences become obvious instead of memorised. Then you will learn how your test cases change for each style.

One Requirement, Three APIs

The mobile banking app needs: customer name, account balance and the last 2 transactions. Let’s see how each API style delivers it.

REST: several resource URLs

GET /v1/customers/42
GET /v1/accounts/ACC-4521
GET /v1/accounts/ACC-4521/transactions?limit=2

{ "data": { "id": "ACC-4521", "type": "savings", "balance": 18400.50,
            "currency": "INR", "branch": "Pune Camp", "ifsc": "SQAT0000123",
            "opened_on": "2019-06-11", "nominee": "...", "...": "many more fields" } }

Three round trips, and the account call returns many fields the screen never shows (over-fetching). Getting both pieces of data with one call isn’t possible (under-fetching), unless the team builds a custom endpoint.

SOAP: one operation, XML envelope

POST /CoreBankingService HTTP/1.1
Content-Type: text/xml; charset=utf-8
SOAPAction: "GetAccountSummary"

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
                  xmlns:cb="http://bank.example.com/core">
  <soapenv:Header><wsse:Security>...signed token...</wsse:Security></soapenv:Header>
  <soapenv:Body>
    <cb:GetAccountSummary>
      <cb:CustomerId>42</cb:CustomerId>
      <cb:TxnCount>2</cb:TxnCount>
    </cb:GetAccountSummary>
  </soapenv:Body>
</soapenv:Envelope>

Always POST, always XML, operation defined in the WSDL. Verbose, but every field, type and error is strictly defined.

GraphQL: one query, exact fields

POST /graphql
{
  customer(id: 42) {
    name
    account { balance currency }
    transactions(last: 2) { date amount description }
  }
}

One request, and the response contains exactly those fields and nothing else.

REST vs SOAP vs GraphQL: Comparison Table

REST in Detail (with a Live Example)

REST follows six constraints: client-server, stateless, cacheable, uniform interface, layered system and (optional) code on demand. For testers the important ideas are: resources as URLs, methods as actions and status codes as results.

Request the same user in JSON (default) and, with content negotiation, in XML. REST lets one resource have several representations:

curl -i \
  -H "Accept: application/xml" \
  "https://sqatools.in/wp-json/sqa-api/v1/users/1"

Change the Accept header to text/csv and the API replies 406 Not Acceptable, a great negative test.

SOAP in Detail

A SOAP message has four parts:

• Envelope (mandatory): root element that marks the XML as a SOAP message.
• Header (optional): security tokens, transaction ids, routing.
• Body (mandatory): the operation and its parameters, or the response.
• Fault (inside Body, on errors): faultcode, faultstring and detail.

<soap:Body>
  <soap:Fault>
    <faultcode>soap:Client</faultcode>
    <faultstring>Invalid account number</faultstring>
    <detail><cb:ErrorCode>ACC-404</cb:ErrorCode></detail>
  </soap:Fault>
</soap:Body>

You will test SOAP hands-on in the SoapUI lessons of Module 4.

GraphQL in Detail

GraphQL has three operation types:

• Query: read data.
• Mutation: create, update or delete data.
• Subscription: real-time updates, usually over WebSocket.

// Partial success: HTTP 200, but one field failed
{
  "data": { "customer": { "name": "Asha Verma", "transactions": null } },
  "errors": [
    { "message": "Not authorised to view transactions", "path": ["customer", "transactions"] }
  ]
}

This is the biggest trap for testers coming from REST: a 200 does not mean success. Always assert that errors is absent (or contains what you expect).

How Test Cases Differ for Each Style

Playwright Example: Testing REST and GraphQL the Same Way

Playwright’s request fixture can call any HTTP API, so the same framework covers REST, GraphQL and even SOAP (as a POST with an XML body).

import { test, expect } from '@playwright/test';

test('REST: content negotiation returns XML', async ({ request }) => {
  const res = await request.get('https://sqatools.in/wp-json/sqa-api/v1/users/1', {
    headers: { Accept: 'application/xml' },
  });
  expect(res.status()).toBe(200);
  expect(res.headers()['content-type']).toContain('application/xml');
  expect(await res.text()).toContain('<name>Asha Verma</name>');
});

test('GraphQL: assert data AND errors', async ({ request }) => {
  const res = await request.post('https://example.com/graphql', {
    data: { query: '{ user(id: 1) { name email } }' },
  });
  expect(res.status()).toBe(200);
  const body = await res.json();
  expect(body.errors).toBeUndefined();          // the important GraphQL check
  expect(body.data.user.name).toBe('Asha Verma');
});

test('SOAP: post an XML envelope', async ({ request }) => {
  const envelope = `<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
      xmlns:tem="http://tempuri.org/"><soapenv:Body>
      <tem:Add><tem:intA>5</tem:intA><tem:intB>7</tem:intB></tem:Add>
    </soapenv:Body></soapenv:Envelope>`;
  const res = await request.post('http://www.dneonline.com/calculator.asmx', {
    headers: { 'Content-Type': 'text/xml; charset=utf-8', SOAPAction: '"http://tempuri.org/Add"' },
    data: envelope,
  });
  expect(res.status()).toBe(200);
  expect(await res.text()).toContain('<AddResult>12</AddResult>');
});

The GraphQL URL above is a placeholder; replace it with your project’s endpoint. The SOAP calculator is a free public demo service.

When to Choose Which (Decision Guide)

• Choose REST for public APIs, CRUD-style apps, mobile backends and anything that benefits from HTTP caching.
• Choose SOAP when a partner or regulator requires it, or you need WS-Security signing and distributed transactions.
• Choose GraphQL when many different clients (web, Android, iOS, smart TV) need different shapes of the same data and you want to avoid many custom endpoints.

Common Myths

• “REST always uses JSON.” No, REST can return XML, CSV or anything; the practice API returns XML when asked.
• “SOAP is dead.” No, it still runs core systems in banking, insurance, airlines and government.
• “GraphQL replaces REST.” Most companies run both; GraphQL often sits in front of REST services.
• “SOAP only works over HTTP.” It can also use SMTP, JMS and other transports.

Interview Questions: REST vs SOAP vs GraphQL

Types of APIs: REST, SOAP, GraphQL, gRPC, WebSocket and Webhooks

“Which types of APIs have you tested?” is one of the most common API testing interview questions, and a weak answer instantly shows a lack of real experience. In this lesson you will learn both ways to classify APIs (by who can use them and by how they are built), see a real product that uses each type, and learn what a tester must check differently for each one.

Classification 1: Types of APIs by Access

1. Open APIs (Public APIs)

Available to any developer, sometimes with a free API key. They usually have strict rate limits.

What to test: rate limiting (429 Too Many Requests), API key validation, clear documentation matches behaviour, backward compatibility between versions, and behaviour under abuse such as huge page sizes.

2. Partner APIs

Shared only with business partners under a contract. Access is given after onboarding, often with stronger authentication (OAuth 2.0 client credentials, mutual TLS, IP allow-listing).

What to test: contract (field names, formats) exactly as agreed, sandbox vs production behaviour, signature or HMAC validation, idempotency keys (so a retry doesn’t charge a customer twice), and webhook callbacks.

3. Internal APIs (Private APIs)

Used only inside a company, between its own apps and services. Most APIs a tester works on daily are internal.

What to test: business rules, integration between services, authorization between roles, and data consistency. Don’t assume “internal” means “safe”: internal APIs are a frequent source of data leaks.

4. Composite APIs

One API call that internally triggers several other API calls and returns a combined answer. Often provided by a Backend-for-Frontend (BFF) layer to reduce mobile network calls.

What to test: partial failures (what if the tracking service is down: error, or a response with tracking missing?), timeouts, correct merging of data, and performance of the whole chain.

Classification 2: Types of APIs by Architecture and Protocol

REST APIs

REST (Representational State Transfer) is an architectural style, not a protocol. Everything is a resource with a URL (/users/1), and you act on it with HTTP methods (GET, POST, PUT, PATCH, DELETE). It is stateless, cacheable and uses standard status codes.

curl -i \
  "https://sqatools.in/wp-json/sqa-api/v1/products/101"

What to test in REST: correct methods and status codes, JSON schema, filters and pagination, headers (ETag, caching), authentication, idempotency of PUT and DELETE.

SOAP APIs

SOAP (Simple Object Access Protocol) is a strict, XML-based protocol. Every message is an XML envelope with an optional header and a body. The contract is described in a WSDL file, which tools such as SoapUI read to generate requests automatically.

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
                  xmlns:bank="http://example.com/bank">
  <soapenv:Header>
    <bank:AuthToken>abc123</bank:AuthToken>
  </soapenv:Header>
  <soapenv:Body>
    <bank:GetBalance>
      <bank:AccountNumber>XXXX4521</bank:AccountNumber>
    </bank:GetBalance>
  </soapenv:Body>
</soapenv:Envelope>

What to test in SOAP: WSDL validity, XML schema (XSD) compliance, SOAP Faults for errors (usually HTTP 500 with a <soap:Fault>), WS-Security headers, and XPath assertions on response values.

GraphQL APIs

GraphQL has a single endpoint (usually POST /graphql). The client writes a query that asks for exactly the fields it needs, so there is no over-fetching or under-fetching.

query {
  user(id: 1) {
    name
    orders(last: 2) { id total status }
  }
}

What to test in GraphQL: queries and mutations, field-level authorization, errors returned inside an errors array (often with HTTP 200!), deeply nested queries that could overload the server (query depth and complexity limits), and introspection being disabled in production.

gRPC APIs

gRPC, created by Google, sends compact binary messages (Protocol Buffers) over HTTP/2. The contract lives in a .proto file. It is much faster than JSON, supports streaming, and is popular for internal microservice traffic.

service PriceService {
  rpc GetPrice (PriceRequest) returns (PriceReply);
}
message PriceRequest { int32 product_id = 1; string pincode = 2; }
message PriceReply  { double price = 1; string currency = 2; }

What to test in gRPC: gRPC status codes (OK, NOT_FOUND, INVALID_ARGUMENT, DEADLINE_EXCEEDED), deadlines and timeouts, streaming behaviour, and backward compatibility of the .proto file. Tools: Postman (gRPC requests), grpcurl, BloomRPC-style clients and k6.

WebSocket APIs

A WebSocket opens one long-lived connection where both sides can send messages at any time. No repeated polling.

What to test: connection handshake (HTTP 101 Switching Protocols), message order and format, reconnection after network drop, authentication on connect, heartbeat/ping, and load with many simultaneous connections.

Webhooks (Reverse APIs)

With a normal API you call the server. With a webhook, the server calls you when an event happens, by sending an HTTP POST to a URL you registered.

What to test: signature verification (reject tampered payloads), duplicate deliveries (the same event twice must not ship two parcels), retries when your endpoint is down, ordering of events, and quick 2xx acknowledgement. Tools such as webhook.site help you capture webhook calls while testing.

Which API Type Should You Learn First?

1. REST: over 80% of the APIs you will test. Master it first (this course focuses on it).
2. SOAP with SoapUI, if you target banking, insurance or service companies with enterprise clients.
3. GraphQL: growing fast in product companies.
4. WebSocket, webhooks and gRPC: learn the concepts and test approach; tools are similar.

Testing Checklist by API Type

Interview Questions: Types of APIs

How an API Works: Request, Response and Endpoints Explained

Before you can test an API you need to see exactly what travels between the app and the server. In this lesson we follow one food order from the moment you tap “Place Order” until the confirmation appears, then break every API request and response into its parts: URL, method, headers, body, status code. Every concept is shown on a live endpoint you can call right now.

The Client-Server Model in Plain Words

Every API conversation has two sides:

• Client: whoever asks. It can be a mobile app, a website running in the browser, Postman, a Playwright test, or another backend service.
• Server: whoever answers. It receives the request, checks who you are, applies business rules, reads or writes the database, and replies.

The client and server can be written in totally different languages. A Swift iPhone app can talk to a Java server, which can talk to a Python pricing service. They understand each other because they agree on the same HTTP protocol and data format (usually JSON).

Step-by-Step: What Happens When You Place a Food Order

1. You tap Place Order. The app builds a request: POST https://api.foodapp.com/v1/orders with your token in the Authorization header and the items in a JSON body.
2. DNS converts api.foodapp.com into an IP address.
3. A secure HTTPS (TLS) connection is opened so nobody on the Wi-Fi can read the data.
4. An API gateway checks the token and the rate limit, then forwards the request to the order service.
5. The order service validates the items, asks the pricing service for the total, reserves stock and saves the order in the database.
6. The server replies 201 Created with the new order id and total.
7. The app reads the JSON and shows “Order placed! Arriving in 32 minutes.”

As a tester, steps 1 and 6 are what you control and observe. Everything in between is the “black box” you are testing through its API.

Anatomy of an API URL

Take this real endpoint from the SQA Tools practice API:

https://sqatools.in/wp-json/sqa-api/v1/users?role=admin&sort=age&order=desc

Everything up to and including the version is called the base URL: https://sqatools.in/wp-json/sqa-api/v1. Each resource path added to it, together with a method, is an endpoint.

Endpoint = Method + Path

The same path can be several endpoints, depending on the HTTP method:

The {id} part is a path parameter. You will study path and query parameters in depth in this lesson.

The 4 Parts of an API Request

1. Method (verb)

Tells the server what you want to do: GET read, POST create, PUT replace, PATCH update, DELETE remove. Full details in HTTP Methods.

2. URL (where)

Base URL + resource path + optional query string.

3. Headers (extra information about the request)

Content-Type: application/json      (the body I am sending is JSON)
Accept: application/json            (please answer in JSON)
Authorization: Bearer eyJhbGciOi... (this is who I am)
X-Request-Id: 7f3c-91aa             (trace id for debugging)

4. Body (payload, the data you send)

Used with POST, PUT and PATCH. GET and DELETE normally have no body.

{
  "name": "Laptop bag",
  "data": { "color": "black", "qty": 1 },
  "ttl": 120
}

The 3 Parts of an API Response

1. Status code

A 3-digit number that summarises the result. 2xx success, 3xx redirect, 4xx your (client) mistake, 5xx server failure. See the complete status code list.

2. Response headers

For example Content-Type, Location (URL of a newly created item), ETag (version for caching), Retry-After, and pagination headers such as X-Total-Count.

3. Response body

The data itself, or an error object. The practice API always uses the same error format, which is good API design and easy to assert:

{
  "error": {
    "status": 404,
    "code": "not_found",
    "message": "User 999 does not exist. Valid ids are 1 to 12."
  }
}

See a Full Request and Response Live

Press Send request to create a temporary object (it deletes itself after 2 minutes). Look at the status 201, the Location header and the ETag header in the result.

curl -i \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"name":"Laptop bag","data":{"color":"black","qty":1},"ttl":120}' \
  "https://sqatools.in/wp-json/sqa-api/v1/objects"

Here is the same conversation written out as raw HTTP, which is how it really looks on the wire:

POST /wp-json/sqa-api/v1/objects HTTP/1.1
Host: sqatools.in
Content-Type: application/json
Accept: application/json

{"name":"Laptop bag","data":{"color":"black","qty":1},"ttl":120}

HTTP/1.1 201 Created
Content-Type: application/json; charset=UTF-8
Location: https://sqatools.in/wp-json/sqa-api/v1/objects/obj_hoeovqif1v
ETag: "v1"

{"id":"obj_hoeovqif1v","name":"Laptop bag","data":{"color":"black","qty":1},
 "version":1,"created_at":"2026-11-12T08:03:29Z","ttl_seconds":120, ...}

Writing the Same Request in Code

cURL

curl -i -X POST "https://sqatools.in/wp-json/sqa-api/v1/objects" \
  -H "Content-Type: application/json" \
  -d '{"name":"Laptop bag","data":{"color":"black","qty":1},"ttl":120}'

The -i flag prints response headers, which testers almost always want to see.

Playwright with TypeScript

import { test, expect } from '@playwright/test';

const BASE = 'https://sqatools.in/wp-json/sqa-api/v1';

test('create an object and read it back', async ({ request }) => {
  // 1. Request: method + URL + headers + body
  const create = await request.post(`${BASE}/objects`, {
    data: { name: 'Laptop bag', data: { color: 'black', qty: 1 }, ttl: 120 },
  });

  // 2. Response: status, headers, body
  expect(create.status()).toBe(201);
  const location = create.headers()['location'];
  const created = await create.json();
  expect(location).toContain(created.id);
  expect(created.version).toBe(1);

  // 3. Prove it was saved: GET the Location URL
  const read = await request.get(location);
  expect(read.ok()).toBeTruthy();
  expect((await read.json()).name).toBe('Laptop bag');
});

Passing an object to data makes Playwright set Content-Type: application/json automatically.

Synchronous vs Asynchronous APIs

Most REST calls are synchronous: you wait and get the result in the same response. Some work takes too long, like generating a 50-page bank statement. Then the API is asynchronous:

1. POST /statements returns 202 Accepted with a job id.
2. The client polls GET /statements/jobs/{id} until the status is "done", or the server calls the client back with a webhook.

Testing async APIs means checking the 202, the job status changes, timeouts and the final result. We cover webhooks in a later module.

Stateless: Why Every Request Must Carry Everything

REST APIs are stateless: the server does not remember your previous request. That is why your token goes in every request header. For testers this means:

• Each test can be run alone, in any order, which makes parallel automation easy.
• If a test passes only after another test ran first, it has a hidden dependency. Create your own test data inside each test instead.

Common Mistakes Beginners Make

• Checking only the status code and not the body. A 200 with the wrong total is still a bug.
• Forgetting Content-Type: application/json when sending a JSON body by hand (cURL). The practice API answers 415 Unsupported Media Type.
• Mixing up the base URL and the endpoint path, or adding double slashes.
• Not verifying that a create or update was really saved with a follow-up GET.
• Hardcoding ids that another tester or test run may delete.

Interview Questions: How APIs Work

What Is API Testing? A Beginner’s Guide with Real-Life Examples

Every time you pay with UPI, track a Swiggy order or check the weather on your phone, dozens of APIs talk to each other behind the screen. If one of them sends wrong data, the app breaks, even when the screen looks perfect. In this lesson you will learn what API testing is, why companies depend on it, what exactly a tester checks, and you will send your first real API request on a free practice API.

What is an API? (The Restaurant Waiter Example)

API stands for Application Programming Interface. It is a contract that lets one piece of software ask another piece of software for data or for an action, using a fixed set of rules.

Map that to software:

What Is API Testing?

API testing means acting like the client: you send requests to the API and verify that every response is correct. You are not clicking buttons. You are checking the layer that every button eventually calls.

When you test an API you ask questions like:

• Does GET /users/1 return 200 OK and the right user?
• Does GET /users/999 return 404 Not Found with a clear error message, not a 500 crash?
• Does creating an order with a negative quantity get rejected?
• Can a user without permission delete someone else’s data?
• Does the API answer in under 500 ms when 1,000 users call it together?

Why API Testing Is So Important

Modern applications are built as many small services talking over APIs. A single Flipkart checkout can call the cart service, pricing service, coupon service, payment gateway, inventory and delivery partner APIs. The UI is just a thin layer on top.

Because of this, API testing is one of the most requested skills in QA job descriptions in 2026, for both manual testers and automation engineers.

Real-Life Example: Testing a Food Delivery Order API

Imagine you are the tester for a food delivery app. The developer tells you the new endpoint POST /orders is ready, but the UI will take another two weeks. With API testing you do not wait. You test it today.

1. Happy path: send a valid order with 2 items. Expect 201 Created, an order id, the correct total and status "placed".
2. Calculation check: 2 x Rs 799 + 1 x Rs 349 = Rs 1,947. Add 18% tax and the total must be Rs 2,297.46. (This exact order exists on the practice API as GET /orders/5001.)
3. Negative tests: quantity 0, unknown item id, missing address. Each should return 400 or 422 with a clear message.
4. Security: call without a login token (expect 401), call with another customer’s token for this order (expect 403 or 404).
5. Performance: response time under the agreed SLA, for example 800 ms.

By the time the UI arrives, the business logic is already proven. UI testers only need to check that the screen shows what the API returns.

What Do You Check in API Testing?

You will learn each of these in detail in the next lessons, especially HTTP status codes and HTTP headers.

Your First API Test in 3 Ways

SQA Tools gives you a free practice REST API with no sign-up. Its base URL is https://sqatools.in/wp-json/sqa-api/v1. Let’s fetch user number 1.

1. In the browser (press Send request)

curl -i \
  "https://sqatools.in/wp-json/sqa-api/v1/users/1"

You should see 200 OK and a JSON body with "name": "Asha Verma", "role": "admin" and "city": "Pune". This data is hardcoded, so the response is always the same, which makes it perfect for practising assertions.

2. In Postman (manual testing)

1. Open Postman and click New → HTTP Request.
2. Keep the method as GET and paste https://sqatools.in/wp-json/sqa-api/v1/users/1.
3. Click Send. Check the status (200), time (ms) and body.
4. Now change the id to 999 and send again. You get 404 with the message “User 999 does not exist. Valid ids are 1 to 12.” That is your first negative test.

3. With Playwright and TypeScript (automation)

import { test, expect } from '@playwright/test';

const BASE = 'https://sqatools.in/wp-json/sqa-api/v1';

test('GET /users/1 returns Asha Verma', async ({ request }) => {
  const response = await request.get(`${BASE}/users/1`);

  expect(response.status()).toBe(200);
  expect(response.headers()['content-type']).toContain('application/json');

  const body = await response.json();
  expect(body.data).toMatchObject({ id: 1, name: 'Asha Verma', role: 'admin', city: 'Pune' });
});

test('GET /users/999 returns 404 with a clear message', async ({ request }) => {
  const response = await request.get(`${BASE}/users/999`);

  expect(response.status()).toBe(404);
  const body = await response.json();
  expect(body.error.code).toBe('not_found');
});

Run it with npx playwright test. No browser opens: Playwright’s request fixture sends pure HTTP calls. You will build full frameworks with this later in the course, and you can already read Playwright API testing basics.

Manual vs Automated API Testing

Real teams use both. A tester explores the new endpoint manually in Postman, writes the test cases, then automates the stable ones so they run on every code change.

Popular API Testing Tools in 2026

• Postman: the most popular GUI tool for manual and scripted REST testing; Newman runs collections in CI.
• SoapUI / ReadyAPI: strong for SOAP web services (WSDL) and also supports REST.
• Playwright (TypeScript): one framework for both UI and API automation; fast, parallel and great reports.
• REST Assured: Java library popular in Selenium + Java teams.
• cURL: command-line tool available everywhere; developers often share bugs as cURL commands.
• JMeter and k6: load and performance testing of APIs.
• Swagger UI: interactive documentation where you can try endpoints in the browser.

Common Bugs Found by API Testing

• Wrong status codes, such as 200 OK with an error message inside the body, or 500 for simple invalid input.
• Missing validation: negative prices, ages of 500, emails without “@” accepted.
• Calculation errors in totals, tax, discounts or currency rounding.
• Broken authorization: user A can read or change user B’s orders by changing the id in the URL (called BOLA/IDOR, the number one API security risk).
• Sensitive data leaks, such as password hashes or internal ids in the response.
• Pagination bugs: the last page repeats records or skips one.
• Slow responses or no rate limiting.
• Contract breaks: a field renamed from user_name to username without telling the mobile team.

How to Start Learning API Testing (Roadmap)

1. Understand how an API works: request, response, endpoint.
2. Learn HTTP methods and status codes.
3. Learn JSON and headers.
4. Practise manually with Postman and cURL on the SQA Tools practice API (141 ready scenarios).
5. Learn authentication: Basic, API key, Bearer JWT.
6. Automate with Playwright and TypeScript, then build the 5 projects in this course.
7. Use AI to generate test cases and code faster, and prepare with the interview questions.

API Testing Interview Questions