HTTP Requests and Responses
Read enough of a request to ask a precise question. · Technical Fluency · Lesson 18 · 3 min
HTTP Requests and Responses · 3 min
Situation
A screenshot says “Something went wrong.”
An engineer asks which request failed and what status it returned. The screenshot alone does not reveal whether the user lacked permission, the input was invalid, or a server dependency failed.
HTTP provides a shared way to express requests and responses. You do not need to memorize every code to follow the conversation.
Mental model
Method, destination, context, result.
A request includes a method, a URL, headers, and sometimes a body. A response includes a status, headers, and often a body.
GET retrieves a resource. POST submits data or requests an operation. PATCH applies a partial change. DELETE requests removal. The endpoint's documented behavior matters more than guessing from its name.
Example
A small change over the wire.
PATCH /api/tasks/42
Content-Type: application/json
{"title": "Review launch plan"}The client asks to change task 42's title. A success response may include the updated task. A failure response should give enough structured information for the interface to explain what the user can do next.
Interpret · Client
Check the request and access.
A 400 often indicates a bad request. A 401 relates to missing or invalid authentication; a 403 commonly means access is forbidden. A 404 means not found, sometimes intentionally hiding a protected resource. A 429 means too many requests.
The code is a clue, not a complete diagnosis. Read the response body and correlate it with server evidence.
Interpret · Server
Accepted is not always finished.
A 2xx code generally indicates success, but 202 can mean accepted for later processing. The interface may still need to show progress and check the eventual result.
A 5xx indicates a server-side failure. Ask which component failed and whether the operation could have partially completed before recommending a retry.
Failure case
Retrying can repeat the action.
If the client times out while creating an order, the server may still have completed it. Retrying a POST without duplicate protection can create a second order.
Ask whether retries are safe, how the client checks the final outcome, and how one user intent is recognized across repeated requests.
Remember this
Translate the failure into a useful report.
Include the action, time, affected environment, request identifier when available, and observed status. Keep credentials and sensitive payloads out of ordinary bug reports.