API testing interview questions

I check the key body values against what I sent or expect, the schema and data types, important headers such as Content-Type, and response time. I also verify side effects with a follow-up call, for example a GET after a POST to confirm the record was saved correctly.

401 means the server does not know who you are because the credentials are missing, invalid or expired. 403 means it knows who you are but you are not allowed to do this. For example, a normal user's valid token calling an admin endpoint should get 403.

A request is idempotent if repeating it has the same effect on the server as sending it once. GET, PUT and DELETE are idempotent, while POST usually is not. It matters because clients retry after timeouts, so I test what happens when the same POST is sent twice, such as whether a payment is charged twice.

I would send requests with missing required fields, wrong data types, values just over length limits, malformed JSON, and a duplicate email. Each should return a 4xx code with a clear message and no stack traces. A 500 response to any of these is a defect I would report.

PUT replaces the whole resource with what you send, so leaving a field out can clear it. PATCH updates only the fields included. In testing I check that a PATCH with only a phone number leaves the name and email unchanged.

I create two test users and get a token for each. Then I use user A's token to request, update or delete user B's resources by changing the id in the URL. The API should return 403 or 404, never B's data, and I treat any success as a serious security defect.