Web & API Testing

Almost every product is a client and a server exchanging messages over the HTTP protocol. While the UI is still being built, the API can already be called directly — send a request, read a structured response. A tester who can do this finds bugs earlier, covers negative and edge cases the interface can never reproduce, and says exactly where things broke — backend or UI.

This topic assembles the base vocabulary of that layer — HTTP methods and status codes, idempotency, the JSON and XML formats, the REST versus SOAP approaches, headers, authentication, and tools like Postman. The traps are named up front — people confuse code 401 (not authenticated) with 403 (not allowed), call POST idempotent, label REST a protocol, and reverse who actually encrypts the traffic — HTTP or HTTPS. The full map lives in the layers below.

Topic map

• What Is an API — a contract for exchanging data with no screen, and why to test it apart from the UI.
• Client-Server Architecture — the request and response roles and what can act as a client.
• HTTP Methods — GET/POST/PUT/DELETE/PATCH and how they map to CRUD.
• GET vs POST — parameters in the URL versus the body, caching, and log visibility.
• Idempotent Methods — why repeating a request is safe and which methods guarantee it.
• HTTP Status Codes — the 1xx–5xx ranges and who is at fault by the first digit.
• Code 401 and Wrong Credentials — 401 versus 403 and when 400 is more correct.
• Request Headers — how the server learns the client's device, OS, and language.
• HTTP vs HTTPS — what TLS adds and why the message shape stays the same.
• JSON Types and Syntax — the six value types and the format's strict rules.
• JSON Syntax Errors — telling a syntax violation apart from a suspicious value.
• XML vs JSON — weight, schemas, namespaces, and where each format fits.
• REST vs SOAP — an architectural style versus a strict protocol.
• REST API Design — noun resources, verb methods, and correct status codes.
• WSDL Contract — a machine-readable description of a SOAP service in XML.
• Postman Variables — reusing values and the narrowest-scope-wins rule.
• Kafka Delivery Semantics — where duplicates come from and how deduplication removes them.

Common traps

Interview relevance

The Web/API block is a favourite check for junior and middle testing roles. The interviewer looks not at memorized codes but at whether you separate the contract from the implementation — the method from the effect, the status from the body, the style from the protocol. A candidate who answers "wrong login" with a confident 401 and explains the difference from 403 immediately gets ahead of "I'd return 200 with an error in the body".

Typical checks:

• The client and server roles, and that a client is not only a browser.
• HTTP methods and their CRUD mapping, the GET/POST difference, idempotency.
• Status-code ranges and the exact code for wrong credentials.
• The JSON/XML formats, syntax rules, the REST versus SOAP difference, and the purpose of WSDL.
• The ability to read a raw request/response in Postman or DevTools and find a bug in the body or headers.

Common wrong answer: "REST is a protocol, and POST is idempotent because it has a body". In fact REST is an architectural style over plain HTTP, and idempotency is about the server's resulting state, not about having a body; POST is not idempotent precisely because each call creates a new resource.