Which HTTP methods are safe or idempotent, and how do status codes and caching fit?

HTTP vests request semantics in the method, not in the URI. RFC 9110 defines two properties that interviewers use constantly.

Safe methods have essentially read-only semantics: they should not have the significance of taking an action other than retrieval. RFC 9110 defines GET, HEAD, OPTIONS and TRACE as safe.

Idempotent methods have the same intended effect on the server whether they are issued once or several times with identical requests. RFC 9110 defines PUT, DELETE, and all safe methods as idempotent. POST is neither safe nor idempotent. Automatic retries after a connection failure are allowed for idempotent methods under the conditions in Section 9.2.2.

PATCH is defined separately in RFC 5789. It applies a partial modification described by a patch document. PATCH is neither safe nor idempotent as specified, although a particular patch media type can be designed to be idempotent.

A compact map, following RFC 9110 (and RFC 5789 for PATCH):

Zalando's guidelines require teams to use these HTTP methods with their standardized semantics and, as a should-rule, to consider making POST and PATCH idempotent in design (for example with a secondary key or an Idempotency-Key header) even though the HTTP specifications do not require it.

A response includes a three-digit status code (RFC 9110, Section 15). The classes are 1xx informational, 2xx successful (200, 201, 204), 3xx redirection (304), 4xx client error (400, 401, 403, 404, 409, 429) and 5xx server error (500, 503). Zalando requires official status codes used with their intended semantics, the most specific applicable code, and Problem JSON (application/problem+json) for error bodies. APIs must not expose stack traces.

Caching is a first-class REST constraint and a first-class part of HTTP. RFC 9110 points to RFC 9111 for cache behaviour. Freshness is controlled by fields such as Cache-Control and Expires, validators such as ETag and Last-Modified, and conditional requests (If-None-Match, If-Modified-Since). GET and HEAD are the usual cache targets. Other methods are not cacheable by default; a POST response can be stored only when explicit freshness information is present, as specified in RFC 9111. Intermediaries can only reuse a response when the message itself says that this is allowed.

Example: a cacheable GET and a Problem JSON error.

GET /product-offers?q=navy%20sneakers&limit=2 HTTP/1.1
Host: catalog.example.com
Accept: application/json

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: private, max-age=30
ETag: "p-offers-77"

{
  "items": [
    {
      "id": "p-1001",
      "title": "Navy sneakers",
      "price": {"amount": 79.95, "currency": "EUR"}
    }
  ]
}

HTTP/1.1 404 Not Found
Content-Type: application/problem+json

{
  "type": "https://api.example.com/problems/not-found",
  "title": "Product offer not found",
  "status": 404,
  "detail": "No product offer with id p-9999."
}

Alternate interview scenarios