Web & API Testing
Client-server fundamentals for testers — HTTP methods and status codes, REST vs SOAP, JSON, authentication, and request/response inspection.
19 questions
JuniorTheoryVery commonWhat are the HTTP status-code ranges, and name a key code in each?
What are the HTTP status-code ranges, and name a key code in each?
1xx is informational, 2xx success (200 OK, 201 Created, 204 No Content), 3xx redirection (301/302), 4xx a client error (400 Bad Request, 401, 403, 404), 5xx a server error (500, 502, 503). The first digit signals who is responsible — the client sent something wrong (4xx) or the server failed (5xx).
Common mistakes
- ✗Mixing up which range means client vs server error
- ✗Treating 401 and 403 as the same code
- ✗Assuming any non-200 code means the server crashed
Follow-up questions
- →What status code does a wrong login and password return?
- →How do 301 and 302 redirects differ?
JuniorTheoryVery commonWhat is an API, and why test it separately from the UI?
What is an API, and why test it separately from the UI?
An API is a contract that lets systems exchange data without a graphical screen — the client sends a request, the server returns a structured response. Testing it separately is faster, can start before the UI exists, isolates backend bugs from UI bugs, and makes negative and edge cases easy to cover and automate.
Common mistakes
- ✗Confusing the API with the UI it serves
- ✗Believing API tests can only start after the UI is ready
- ✗Thinking UI testing makes API testing redundant
Follow-up questions
- →Which classes of bugs are easier to find at the API level than the UI?
- →What tool would you use to send a raw API request by hand?
MiddleTheoryVery commonHow do GET and POST differ, and how are GET parameters passed?
How do GET and POST differ, and how are GET parameters passed?
GET reads data and passes parameters in the URL query string (?a=1&b=2), so it is cacheable, idempotent, length-limited, and visible in logs. POST creates or submits data in the request body, is not cached, and is not idempotent.
Common mistakes
- ✗Swapping which method is cacheable and idempotent
- ✗Saying
GETcannot pass parameters - ✗Believing
POSTdata is visible in the URL
Follow-up questions
- →Why is putting sensitive data in a
GETquery string risky? - →Why is
GETconsidered idempotent butPOSTis not?
JuniorTheoryCommonWhat is client-server architecture, and what can act as the client?
What is client-server architecture, and what can act as the client?
In client-server architecture the client sends a request, the server processes it and returns a response; the two communicate over a network protocol such as HTTP. The client is anything that initiates requests — a browser, a mobile app, another backend service, a CLI tool, or an IoT device — not only a person at a screen.
Common mistakes
- ✗Thinking only a browser can be a client
- ✗Reversing the roles — claiming the server initiates requests
- ✗Assuming client and server must run on one machine
Follow-up questions
- →How does the server know which client device and language sent a request?
- →Name a non-browser client and the protocol it would use.
JuniorTheoryCommonName the main HTTP methods and the purpose of each.
Name the main HTTP methods and the purpose of each.
The four base methods map to CRUD: GET reads a resource, POST creates a new one, PUT replaces or fully updates one, DELETE removes it. PATCH applies a partial update. GET carries parameters in the URL query string; POST, PUT, and PATCH carry data in the request body.
Common mistakes
- ✗Swapping the read/create roles of
GETandPOST - ✗Believing
GETcarries data in a body - ✗Confusing
PUT(full replace) withPATCH(partial update)
Follow-up questions
- →How do
GETandPOSTdiffer in caching and parameter passing? - →Which of these methods are idempotent and why?
MiddleTheoryCommonWhich HTTP methods are idempotent, and what does idempotent mean?
Which HTTP methods are idempotent, and what does idempotent mean?
Idempotent means repeating the same request any number of times leaves the server in the same state as sending it once. GET, PUT, DELETE, and HEAD are idempotent; POST is not, because each call creates a new resource. Idempotency does not require identical responses — only identical resulting state.
Common mistakes
- ✗Calling
POSTidempotent because it has a body - ✗Requiring identical responses rather than identical state
- ✗Thinking
DELETEis not idempotent because the second call may 404
Follow-up questions
- →Why is
DELETEstill idempotent even if the second call returns 404? - →How does idempotency help when retrying requests after a timeout?
MiddleDesignCommonDesign a clean REST API for an exchange-user system. For each operation give the URL, the HTTP method, and the success status code: create a user for a specific exchange, get all users, get one specific user on a specific exchange, and grant a user access to a specific exchange. Explain your resource naming and versioning choices, why you picked each method and status code, and what makes the design RESTful.
Design a clean REST API for an exchange-user system. For each operation give the URL, the HTTP method, and the success status code: create a user for a specific exchange, get all users, get one specific user on a specific exchange, and grant a user access to a specific exchange. Explain your resource naming and versioning choices, why you picked each method and status code, and what makes the design RESTful.
Use plural noun resources and a version prefix: POST /v1/exchanges/{id}/users → 201 (create on an exchange); GET /v1/users → 200; GET /v1/exchanges/{id}/users/{userId} → 200 (one user); grant access is creating an access resource: POST /v1/exchanges/{id}/users/{userId}/access → 201, or PUT the membership → 200. It is RESTful because resources are nouns in the URL, the HTTP verb carries the action, status codes are used correctly, and the design is stateless and consistently versioned.
Common mistakes
- ✗Putting verbs in the URL instead of using HTTP methods
- ✗Returning 200 for a creation instead of 201
- ✗Using GET for operations that change state
Follow-up questions
- →Which of these endpoints are idempotent, and why does that matter?
- →How would you version the API without breaking existing clients?
SeniorTheoryCommonWhat HTTP authentication methods do you know, and how do they differ?
What HTTP authentication methods do you know, and how do they differ?
Common schemes: Basic Auth (base64 credentials in a header, safe only over HTTPS), Bearer/JWT tokens, API keys, OAuth 2.0, Digest, session cookies, and mTLS. They differ in where the secret lives, whether it expires, and in delegation.
Common mistakes
- ✗Thinking Basic Auth is safe without HTTPS
- ✗Confusing OAuth 2.0 (delegated authorization) with simple login
- ✗Believing tokens and API keys are interchangeable in security
Follow-up questions
- →Why must Basic Auth always run over HTTPS?
- →What does OAuth 2.0 add that a plain API key does not?
JuniorTheoryOccasionalWhat data types does JSON support, and what are its syntax rules?
What data types does JSON support, and what are its syntax rules?
JSON has six value types: string (always in double quotes), number, boolean (true/false), null, object {}, and array []. Keys must be double-quoted strings. The format forbids trailing commas, comments, single quotes, and leading zeros, and numbers use a dot as the decimal separator.
Common mistakes
- ✗Forgetting strings and keys must use double quotes
- ✗Leaving a trailing comma after the last element
- ✗Using a comma instead of a dot as the decimal separator
Follow-up questions
- →What is the difference between JSON and XML?
- →Why are leading zeros invalid in a JSON number?
MiddleTheoryOccasionalA wrong login and password are sent — what status code should the server return?
A wrong login and password are sent — what status code should the server return?
The precise answer is 401 Unauthorized — the request lacks valid authentication credentials. 403 Forbidden is different: the user is authenticated but not allowed. Some APIs return 400 Bad Request if the body itself is malformed, but for valid-shaped wrong credentials, 401 is correct.
Common mistakes
- ✗Confusing 401 (not authenticated) with 403 (not allowed)
- ✗Returning 200 with an error flag instead of a 4xx code
- ✗Treating a rejected login as a 5xx server fault
Follow-up questions
- →When would 403 be the more correct code than 401?
- →Why might an API return 401 for both unknown user and wrong password?
MiddleTheoryOccasionalWhat is the difference between HTTP and HTTPS?
What is the difference between HTTP and HTTPS?
HTTPS is HTTP over TLS: traffic is encrypted, the server is certificate-authenticated, and data is tamper-protected. Plain HTTP is clear text anyone on the path can read or alter. Both use one message shape: status line, headers, body.
Common mistakes
- ✗Reversing which one encrypts traffic
- ✗Thinking HTTPS hides the status codes or headers
- ✗Believing HTTPS authenticates the client, not the server
Follow-up questions
- →How would you confirm a site actually uses a valid TLS certificate?
- →What three guarantees does TLS add on top of HTTP?
MiddleTheoryOccasionalHow does the server know the client's device, browser, OS, and language?
How does the server know the client's device, browser, OS, and language?
It reads request headers the client sends. User-Agent carries the browser, OS, and device; Accept-Language carries the preferred language; the client IP and cookies add more context. The server uses these for content negotiation — serving a localized page or a device-appropriate response — which is why the same URL can return different content per client.
Common mistakes
- ✗Thinking the server scans the device rather than reading headers
- ✗Confusing
User-AgentwithAccept-Language - ✗Assuming one URL must return identical content to all clients
Follow-up questions
- →How could
Accept-Languagemake one device receive a different file? - →Why should a tester not trust the
User-Agentas proof of the real device?
MiddleTheoryOccasionalHow do the web-service approaches REST and SOAP differ?
How do the web-service approaches REST and SOAP differ?
REST is an architectural style around resources and URLs that reuses HTTP verbs, is stateless, and commonly returns JSON — lightweight and flexible. SOAP is a strict protocol that wraps every message in an XML envelope, is described by a WSDL contract, is transport-agnostic, and carries built-in standards like WS-Security — heavier but more formal.
Common mistakes
- ✗Calling REST a protocol rather than an architectural style
- ✗Tying SOAP to a specific transport like HTTP only
- ✗Believing REST cannot use XML or SOAP cannot be tested
Follow-up questions
- →What is the data-format contract called WSDL used for?
- →When would SOAP's strictness be preferable to REST?
SeniorTheoryOccasionalWhat is the difference between synchronous and asynchronous communication?
What is the difference between synchronous and asynchronous communication?
In synchronous communication the caller blocks and waits for the response before continuing. In asynchronous communication the caller continues immediately and the result arrives later via a callback, poll, webhook, or message queue. For testers, async brings timeouts, eventual consistency, and race conditions that synchronous flows avoid.
Common mistakes
- ✗Reversing which mode blocks the caller
- ✗Forgetting async needs callbacks, polling, or queues
- ✗Overlooking the timeouts and race conditions async introduces
Follow-up questions
- →How would you test that an asynchronous job eventually completes?
- →What race conditions can appear only in asynchronous flows?
MiddleTheoryRareFrom a tester's view, why do duplicates appear in Kafka, and how are they handled?
From a tester's view, why do duplicates appear in Kafka, and how are they handled?
Kafka (a message broker passing messages between services) groups messages into partitions, and consumer groups read them in parallel. Duplicates appear under at-least-once delivery: a consumer processes a message but crashes before committing its offset, so it is re-delivered. They are handled by deduplication — idempotent processing keyed on a unique message key, or an idempotent producer, so reprocessing has no extra effect. At-most-once avoids duplicates but risks losing messages.
Common mistakes
- ✗Assuming Kafka is exactly-once by default
- ✗Confusing at-least-once with at-most-once semantics
- ✗Ignoring idempotent processing as the dedup mechanism
Follow-up questions
- →How would you test that a consumer is idempotent?
- →What happens when there are more consumers than partitions?
MiddleTheoryRareWhat are variables in the API tool Postman, and which scope wins on a name clash?
What are variables in the API tool Postman, and which scope wins on a name clash?
Variables let you reuse values (URLs, tokens, ids) across requests instead of hard-coding them. Postman resolves scopes narrowest-wins: Local > Data > Environment > Collection > Global, so a local variable beats a global one of the same name. On a collection run, the collection-level pre-request script runs first, then each request's own pre-request script before that request fires.
Common mistakes
- ✗Thinking the global scope wins over a local one
- ✗Believing all variables share one flat scope
- ✗Expecting per-request scripts to run before the collection script
Follow-up questions
- →Why does the narrowest scope take priority on a name collision?
- →When would you store a token in an environment variable rather than a global one?
MiddleTheoryRareWhat is WSDL, and what is it used for?
What is WSDL, and what is it used for?
WSDL (Web Services Description Language) is an XML document that formally describes a SOAP web service — its operations, the messages and data types they exchange, and the endpoints and bindings. It is the machine-readable contract a client reads to know exactly how to call the service, so tooling can generate client stubs automatically.
Common mistakes
- ✗Associating WSDL with REST/JSON instead of SOAP/XML
- ✗Thinking WSDL is a query or styling language
- ✗Forgetting it is a machine-readable client contract
Follow-up questions
- →How does a WSDL let a client generate code to call the service?
- →Why does REST typically not need a WSDL-style document?
MiddleTheoryRareWhat are the differences between the data formats XML and JSON?
What are the differences between the data formats XML and JSON?
JSON is lighter and maps directly to key-value objects and arrays, is native to JavaScript, and by default has no schema. XML is more verbose, uses nested tags with attributes and namespaces, supports comments, and can be validated against an XSD schema. SOAP services use XML; REST APIs most often use JSON.
Common mistakes
- ✗Claiming JSON cannot represent nested structures
- ✗Believing XML has no schema validation
- ✗Tying each format exclusively to one of REST or SOAP
Follow-up questions
- →Which JSON value types have no direct XML equivalent?
- →When would XML's namespaces and schema be worth the verbosity?
SeniorDebuggingRareFind all JSON syntax errors in this config block
Find all JSON syntax errors in this config block
The block breaks several JSON rules: an unquoted string value (73bf37d59d), a leading zero (01), a comma used as a decimal separator (20,5 must be 20.5), an unquoted key (title_font_style), a trailing comma after "mobile", and a missing closing } on the {type, title} object before its ]. Quoting "false" is legal but likely should be the boolean false.
Common mistakes
- ✗Missing the unquoted key
title_font_style - ✗Overlooking the missing closing brace before the
itemsarray] - ✗Treating the suspicious
"false"string as a hard syntax error
Follow-up questions
- →Why does JSON forbid a leading zero in a number like
01? - →Which of these errors would a linter catch versus a schema validator?