API Testing

Methods & semantics

• GET — retrieve, no body, idempotent, cacheable.
• POST — create, not idempotent (two calls = two resources).
• PUT — full replace/update, idempotent.
• PATCH — partial update, not necessarily idempotent.
• DELETE — remove, idempotent.

401 vs 403 is a classic — 401 means the server doesn't know who you are; 403 means it knows you and you're still not allowed.

For any API response, check beyond just the status line:

1. Status code — correct for the scenario.
2. Response body — correct values and correct data types.
3. Schema — structure matches the contract (JSON Schema: required fields, shape, types).
4. Headers — Content-Type, auth, caching, rate-limit headers.
5. Response time — within the SLA.
6. Side effects — did the POST actually persist? Verify with a follow-up GET.

• API Key — static key in a header or query param.
• Bearer token / JWT — Authorization: Bearer <token>. A JWT is header.payload.signature; the payload carries claims (exp, sub, roles).
• OAuth 2.0 — token-exchange flow; in tests you typically grab a token via client-credentials or password grant in setup, then reuse it.
• Basic Auth — base64 user:pass, rarely used now.

JSON Schema validation

Assert the shape — required fields present, correct types, structure intact — not just individual values. More robust and maintainable than field-by-field assertions when the payload is large.

Contract testing (Pact)

Consumer and provider agree on a contract; it catches breaking changes between services without a full integration environment. It's consumer-driven.

Schema validation checks the shape of one response. Contract testing verifies the agreement between two services stays intact.

• API tests are faster, more stable, and less flaky — no rendering, no waiting on elements.
• They exercise business logic and data integrity directly.
• They sit in the middle of the test pyramid — many fast unit tests at the base, a healthy API/integration layer in the middle, few UI/E2E tests at the top.
• They catch issues earlier and pinpoint failures more precisely than UI tests.

• Mock / stub external dependencies (WireMock, mock servers) to isolate the service under test and control responses.
• Setup / teardown — create preconditions via API, clean up after; keep each test independent and idempotent.
• Environment management — base URLs, secrets, and tokens configured per environment (dev / staging).

RestSharp

var client = new RestClient("https://api.example.com");
var request = new RestRequest("/users/1", Method.Get);
request.AddHeader("Authorization", $"Bearer {token}");
var response = await client.ExecuteAsync(request);

Assert.That(response.StatusCode, Is.EqualTo(HttpStatusCode.OK));
var user = JsonConvert.DeserializeObject<User>(response.Content);
Assert.That(user.Id, Is.EqualTo(1));

Playwright API testing

var request = await playwright.APIRequest.NewContextAsync(new()
{
    BaseURL = "https://api.example.com",
    ExtraHTTPHeaders = new Dictionary<string, string>
    {
        ["Authorization"] = $"Bearer {token}"
    }
});

var response = await request.GetAsync("/users/1");
Assert.That(response.Status, Is.EqualTo(200));
var body = await response.JsonAsync();

Suite structure to raise

• A base / client wrapper class for the HTTP client and auth.
• POCO models for request / response deserialization.
• [SetUp] / [OneTimeSetUp] for token acquisition (NUnit), or fixtures (xUnit).
• Data-driven tests ([TestCase], [TestCaseSource]) for negative cases.
• Separate config per environment.