Interview Corner

A: An API is a set of rules that lets two software systems communicate. The client sends a request, the server processes it and sends a response. Think of a waiter in a restaurant — takes your order to the kitchen, brings back the food. The client never talks to the server directly.

A: REST — Representational State Transfer — is an architectural style for APIs. It uses standard HTTP methods (GET, POST, PUT, DELETE), communicates in JSON, and treats everything as a resource with a unique URL. It's stateless — each request carries all the info the server needs. About 80% of APIs you'll test are REST.

A: GET reads data, POST creates new resources, PUT replaces an entire resource, PATCH updates part of a resource, DELETE removes a resource. GET and DELETE typically have no body. POST, PUT, and PATCH send a JSON body. GET is safe (doesn't change data) and all except POST are idempotent (same result if called multiple times).

A: 2xx = success (200 OK, 201 Created, 204 No Content). 3xx = redirection (301 Moved Permanently). 4xx = client error — your request is wrong (400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found). 5xx = server error — their code broke (500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable).

A: 401 = "who are you?" — no credentials or invalid token. The server doesn't recognize you. 403 = "I know who you are, but you can't do this" — valid token but insufficient permissions. Example: no token → 401. Regular user calling admin endpoint → 403.

A: Path parameters are part of the URL and identify a specific resource: /users/42. They're required. Query parameters come after ? and filter/sort results: /users?role=admin&page=2. They're usually optional. Path params = which resource. Query params = how to filter.

A: JSON — JavaScript Object Notation — is a lightweight data format used by APIs. It's key-value pairs in curly braces. Supports strings, numbers, booleans, null, arrays, and nested objects. It's human-readable and every language can parse it. Example: { "name": "Priya", "age": 26, "active": true }.

A: Three reasons. Speed — runs in milliseconds vs seconds for UI. Coverage — tests business logic directly, catches bugs UI can't reach (like negative amounts). Reliability — doesn't break when CSS changes. In modern apps, most bugs live in the backend. API testing catches them faster and earlier.

A: Status code (matches expected), response body (correct data, all required fields present), data types (number not accidentally a string), no sensitive data leakage (passwords, tokens), response headers (Content-Type, caching), and response time (within SLA). Most testers only check status code and one field — that's not enough.

A: PUT replaces the entire resource — send all fields, missing ones get nulled. PATCH updates only the fields you send — rest stays untouched. Example: user has name, phone, email. PUT with only name and email → phone becomes null. PATCH with only email → name and phone stay the same. Most real apps use PATCH for updates.