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.

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.

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.

No, it is not necessary to actually send real notifications. Instead, you should mock or simulate the external APIs and services. This approach allows you to test the notification logic without depending on third-party services, and it is a good practice for learning how to mock external dependencies in your test suite. If you do want to use a real service for integration testing, AWS SNS is a good option that covers both SMS and push notifications.

The general approach is: 1) Delimit the problem — determine where (which service or process) and when (under what conditions) the failure occurs. 2) Check existing logs in the failing service or process; if none exist, implement logging in the APIs to record every HTTP call along with its response code (e.g., 200 OK, 500 Server Error, 400 Bad Request). Use try/catch blocks to capture and record errors. Consider centralised cloud logging tools such as AWS CloudWatch. 3) Once you have data, try to reproduce the failure consistently so you can analyse it. 4) Investigate common causes of intermittent failures: exhausted connection/request pools (leading to 500 errors when the limit is reached), network or infrastructure issues (e.g., duplicate IPs), or transient third-party service problems. 5) Design a remediation strategy, which may include retry mechanisms, a circuit-breaker pattern to stop cascading failures, a message-queue system that holds failed requests and retries them automatically, or scheduled jobs (e.g., a cron job every 30 minutes) to reprocess failed items. 6) Maintain a historical record of failures to detect patterns over time.