An API problem is easier to investigate when you separate the request, the server decision and the response. Learn what methods, status codes, headers and bodies contribute to that exchange.
Read the complete request
A request has a method, a target URL, headers and sometimes a body. GET commonly retrieves a representation; POST commonly submits data for processing. HTTP method semantics matter for caching and retries. Avoid using a state-changing GET for actions such as deleting a record, because navigation and automated clients can follow links.
Use the status code as one clue
A 2xx status generally indicates success, 4xx indicates a problem with the request or access, and 5xx indicates a server-side failure. The status does not replace the response body. An HTML error page returned to a client expecting JSON can cause a parsing error that hides the original problem.
Design for failure and repeat requests
Networks can fail after a server has processed an action. Retrying a payment or submission blindly may repeat its effect. Important write operations need a deliberate duplicate-handling strategy, such as a server-side idempotency key. Authentication, authorisation and input validation remain server responsibilities even when the browser has already checked the form.
Worked example
For a fictional reading-list API, GET /books/7 returns a JSON representation. If the resource is absent, the server should return a clear not-found response rather than a successful page with no explanation. The example shows the shape of a successful response, not a live endpoint.
{"id":7,"title":"A fictional reading list","available":true}Check your understanding
Try each question before opening its explanation. These are free practice prompts; they do not use game chances.
Does HTTPS make every API request authorised?
No. HTTPS protects data in transit. The application must still identify the caller and check whether that caller may access the requested resource.
What should you inspect when JSON parsing fails?
Inspect the network response status, content type and body. A login redirect or HTML error page may be the actual response, even if the client code expected JSON.
Why should a retry key be checked on the server?
A browser can crash, reload or send duplicate requests. The server is the place that can recognise an already processed action and avoid repeating its stored effect.
Sources and further reading
These original examples explain foundational concepts. Use the official references for complete, current details and version-specific behaviour.
About this guide: AI-assisted educational content with original examples and linked primary references. Found an issue? Tell us what to improve.