= HTTP safe method
{c}
An <HTTP safe method> has essentially read-only requested semantics: the client does not ask the server to change resource state through the operation. `GET` and `HEAD` are examples. The definition concerns what the operation requests, rather than asserting that no incidental activity occurs anywhere on the server.<HTTP Semantics>[§9.2.1, Safe Methods]{ref}
For example, reading a stored color can return `blue` while leaving that color unchanged. The server can still append an access-log entry. A later read can return `red` if some separate operation changed the color in between; safe semantics do not require an unchanging response or an immutable resource.
At the intended-state level, a read-only operation can be modeled as $f(s)=s$. It follows immediately that
$$
f(f(s))=f(s).
$$
This illustrates why safe methods are also idempotent. The converse fails: deletion can map both present and absent states to absent, satisfying <HTTP idempotence> while changing a present resource on its first application.
The chosen <HTTP request method> remains meaningful even when the target <URL> contains a <query string>. Naming a destructive action in a query does not redefine `GET` as a method for requesting that action; the standard requires such actions to be disallowed when accessed through safe methods.<HTTP Semantics>[§9.2.1, actions selected by target-URI parameters]{ref}
Use this term for protocol semantics. Successful transfer, access permission and the truth of returned application data are separate questions. Interpret the method with the target and application contract, rather than deciding safety from whether a response happens to contain a body.
Back to article page
