Analysis of HTTP verbs through a protocol-thinking lens. GET (read): idempotent — retries are always safe because no side effects change. DELETE: idempotent, but receivers must recognize the already-processed case and return a not-found/gone response the sender knows to treat as success. PUT: idempotent per the spec, but only under the single-sender assumption — concurrent senders can cause lost-update races, requiring optimistic locking. PUT can also be used for creation when senders pick IDs (e.g. UUIDv4) large enough that collisions are effectively impossible. POST: not inherently idempotent — on retry the sender cannot know if the resource was created, so idempotency keys or find-or-create fallbacks are needed.