2. API Testing

Common API types include REST (Representational State Transfer), SOAP (Simple Object Access Protocol), and GraphQL. Mention specifically which ones you have hands-on experience with.

SOAP is a protocol that uses XML for message format and is more rigid. REST is an architectural style that can use multiple formats (XML, JSON, HTML, etc.) and is generally more flexible and lightweight.

PUT is used to update a resource entirely (replacing it). PATCH is used to apply partial modifications to a resource.

API chaining is the process of using the response from one API request as the input (request parameter) for a subsequent API request. This is common in testing complex workflows.

Swagger is used for API documentation and testing via a UI. cURL is a command-line tool for transferring data with URLs. Explain your specific usage, e.g., 'I use Swagger to understand endpoints and cURL to verify responses quickly from the terminal.'

Inspect the network tab in browser developer tools. If the API request sends correct data but returns an error or incorrect data, it's likely a backend issue. If the API returns correct data but the UI displays it wrong, it's a frontend issue.

No, a 204 No Content status code means the server successfully processed the request, but is not returning any content.

1xx informational, 2xx success (200 OK, 201 Created, 204 No Content), 3xx redirection (301/302/304), 4xx client error (400, 401, 403, 404, 422), 5xx server error (500, 502, 503). As an SDET you assert the API returns the correct code per scenario — a wrong code (e.g. 200 instead of 404) is a bug.

401 Unauthorized means you are not authenticated — the server does not know who you are, so log in. 403 Forbidden means you are authenticated but lack permission for this resource. Mnemonic: 401 = who are you?, 403 = I know you, but no.

400 Bad Request means the request itself is malformed — invalid JSON, missing required fields, wrong format. 422 Unprocessable Entity means the format is correct but the values fail business rules (e.g. an invalid email or a negative price). Both are client errors, but they point to different bugs.

Safe = does not change server state: GET, HEAD, OPTIONS. Idempotent = calling it N times has the same effect as once: GET, HEAD, OPTIONS, PUT, DELETE. POST is neither (each call can create a new resource). PATCH is not guaranteed idempotent. This matters for retry logic and test design.

PUT replaces the entire resource — any field you omit is lost. PATCH updates only the fields you send, leaving the rest intact. A common interview trap: sending PUT /users/42 with just {name} wipes email and age; PATCH with {name} keeps them.

Use plural resource nouns (/users, not /getUser); no verbs in the URL (the HTTP method is the verb); nest related resources (/users/42/orders); use query params for filtering, sorting and pagination (?category=x&page=2&sort=price). So GET /users, POST /users, GET /users/42, PATCH /users/42, DELETE /users/42.

From most local to most global: data (CSV/JSON for data-driven runs), local (within one request's script), environment (per dev/stg/prod), collection (shared across the collection), global. Reference them as {{baseUrl}}/users/{{userId}}. Keep environment-specific values (baseUrl, credentials) in environment scope and shared constants in collection scope.

Use pm.test with pm.expect (Chai): pm.test('Status 200', () => pm.response.to.have.status(200)). Check the JSON body with pm.expect(body).to.have.property('id'), types with .to.be.a('number'), and that secrets are not exposed with .to.not.have.property('password'). You can also assert response time below a threshold.

Schema validation checks the structure of a response — required fields, types, ranges, enums, allowed values — independently of the exact data. It catches contract regressions (a renamed or missing field) that value assertions miss. In practice you use JSON Schema with a validator like ajv or joi, asserting the response matches before checking individual values.