Methods, status codes & retry meaning

A method describes the requested operation; a status describes an observed response. Keep those axes separate. GET asks for a representation, HEAD asks for corresponding metadata without response content, and OPTIONS asks about communication options. POST submits data for resource-specific processing. PUT requests creation or replacement at its target; DELETE requests removal. PATCH applies a partial modification according to its patch format and API. An endpoint's documentation supplies details beyond those general meanings.

A safe method has read-only requested semantics. GET, HEAD and OPTIONS are the safe methods supported by this lab. This does not forbid incidental logging. An idempotent method has the same intended effect after repeated identical requests as after one. PUT and DELETE are idempotent but not safe. A DELETE can return 204 once and 404 later while leaving the resource equally absent. Do not infer either property for arbitrary POST or PATCH endpoints; an API may add an explicit replay guarantee that this course does not assume.

Status families give an initial interpretation:

The family is not the complete application outcome. A 202 means accepted for processing, not completed processing. A 200 can still contain malformed data for the client. A 401 and a 403 require different authentication/authorization reasoning. A 429 reports rate limiting; a 404 does not automatically justify repeating the same request indefinitely.

safe = {"GET", "HEAD", "OPTIONS"}
idempotent = safe | {"PUT", "DELETE"}
for method in ("GET", "PUT", "POST"):
    print(method, method in safe, method in idempotent)
print(503 // 100)  # the server-error family

Content permission is another independent question. Responses to HEAD have no content. Neither do 1xx, 204, 205 or 304 responses. An ordinary 301 or 404 may contain useful content. Therefore a rule such as “parse the body for every status greater than 199” is insufficient. The classifier's has_body means content is permitted, not that the supplied response necessarily contains any.

The build adds a deliberately narrow retry_candidate: an idempotent method with 429, 502, 503 or 504. This is local client policy, not a promise that replay will succeed or a mandate to retry. A complete policy also limits attempts, checks a wait budget, respects supported Retry-After values and handles transport uncertainty. The capstone makes those decisions inspectable.

Work through PUT 503, POST 503, GET 304 and HEAD 200 before coding. Predict all five output fields independently, then check the family boundaries 199/200, 299/300 and 499/500. The bug hunts separate method safety from idempotence and show why special no-content statuses cannot be derived from family alone.

Read RFC 9110 sections 9 and 15 for method and status semantics, and RFC 6585 section 4 for 429. These definitions inform the lab; the chosen retry set remains explicit application policy.