Summary

  • RFC 9110 makes the method token the primary source of request semantics: it states the client's purpose and expected successful result, while each target resource independently decides whether that method is implemented or allowed.
  • Safe concerns what the client asked for, not the absence of every side effect. Idempotent concerns the intended server effect of repeated identical requests, not identical responses, empty logs or certain recovery.
  • A defensible operation joins method, target, authenticated principal, authorization policy, precondition, first-attempt uncertainty, application-level idempotence, retry actor, response, resulting state and separately observed side effects.

A request arrives as a line that looks decisive. The method comes first. The target follows. Credentials, conditions and content add detail. A gateway sees the method early enough to route, filter, cache or decide whether a lost response can be retried. It is tempting to read the first token as the whole decision.

That temptation confuses vocabulary with authority. A method names an intention shared across implementations. It does not grant the sender a right over the target. A server can recognize the word, implement its semantics, advertise that it is available for a resource and still refuse this principal. It can accept the principal and reject a stale precondition. It can apply the request and lose the response. It can perform the intended change while also writing a log, creating a revision or triggering a downstream effect.

Roy T. Fielding's work on HTTP and REST offers a disciplined way to keep those facts apart. The common interface should reveal enough intention for independent components to cooperate. Resource policy and state stay local. Authorization needs its own principal and scope. Failure recovery needs evidence, not confidence borrowed from a verb.

The method token is a public statement of purpose

RFC 9110 calls the request method token the primary source of request semantics. It indicates why the client made the request and what the client expects a successful result to mean. GET asks for a current representation. PUT asks to create or replace the state represented at a chosen target. DELETE asks to remove the association between the target URI and its current functionality.

This is more precise than an application action label. The semantics are standardized across resources so that a component does not need private knowledge of every application before making a limited inference. A cache can distinguish retrieval from modification. A crawler can treat a safe method differently from an unsafe one. A client can reason about a repeat after a broken connection.

The word remains an intention. A successful PUT does not guarantee that an equivalent representation will still be visible on the next GET; another user agent or dynamic processing might intervene. DELETE does not promise that every stored byte is destroyed or that storage is reclaimed. HTTP deliberately leaves the implementation behind the resource interface hidden.

The first receipt is therefore narrow: which standardized intention did the client express? It is not yet a receipt for permission or final state.

A uniform interface ends before local admission

RFC 9110 gives every resource the right to decide whether a standardized method is implemented or allowed. The distinction is observable. A server should use 501 when it does not recognize or implement the method. It should use 405 when the method is known and implemented but not supported by the target resource. A 405 response includes Allow, listing the target's currently supported methods; the set can change dynamically.

Allow is capability information, not an authorization certificate. It can say that a collection accepts POST or a document supports PUT. It does not prove that an anonymous caller, a service account or the employee behind a browser has the required role. Authentication establishes or tests an identity. Authorization applies policy to that identity, action and target. Method support asks a different question: can this resource process this standardized kind of request at all?

Collapsing the columns creates two opposite errors. A client can refuse a legitimate operation because it treats missing generic metadata as a final security answer. Or it can expose a destructive action because it assumes an advertised method is open to everyone. The response receipt should preserve recognition, resource support and principal authorization as three separate decisions.

This separation resembles Heng Lu's Minimum Initial Specification. The shared layer is strict about the semantics needed for interoperability, while later choices remain with participants operating the resource. A public registry of method meanings coordinates; it does not govern every target.

Safe assigns responsibility; it does not erase side effects

Safe methods are essentially read-only in their defined semantics: the client does not request or expect a state change on the origin server. RFC 9110 immediately limits the inference. A server can append to an access log. Selecting an advertisement can charge an account. An implementation can perform behavior that is not wholly read-only. Those effects do not change what the client asked for, and the client cannot be held accountable for behavior it did not request.

This is an allocation of responsibility, not a claim of physical innocence. It explains why automated retrieval, link checking, indexing and prefetching can operate. The resource owner must keep unsafe actions out of safe methods. A URI such as page?do=delete cannot be allowed to delete when retrieved with GET merely because the action was hidden in a query parameter. A crawler following every link would turn a semantic shortcut into damage.

The operational test has two sides. First, did the client's standardized request semantics ask for a state change? Second, what additional effects did the implementation choose to attach? Calling both “the effect of GET” lets the server transfer its own design choices onto the client.

Safe also does not mean authorized. A confidential representation can be retrieved with a safe method and still require permission. Read-only access can disclose, bill, rate-limit or reveal presence. The method property tells automation how to bound requested harm; the authorization system still decides who may cross the boundary.

Idempotent preserves intended effect, not an identical world

An idempotent method has the same intended server effect when multiple identical requests are applied as when one is applied. PUT, DELETE and safe methods have that property under RFC 9110. The definition again stays with requested intent. A server may log every request separately, retain multiple revision records or create other per-attempt side effects.

Responses can differ too. The first DELETE might remove the URI association and return success. A repeated DELETE may report that the resource is already absent. The intended state is still the same. A repeated PUT can reach the same target state while receiving a new date, validator or representation of the outcome.

Application design can narrow or defeat the useful inference. A nominal PUT endpoint that increments a balance instead of replacing target state violates the visible intent. A DELETE that sends a new irreversible external instruction on every attempt may preserve the local URI state while multiplying downstream consequences. Method-level idempotence is not a universal transaction guarantee.

The receipt needs both layers: the standardized property and the application's evidence that the intended effect is actually deduplicated or convergent. If downstream systems are involved, each effect needs its own idempotency key, commit status or compensation path.

Retry begins with uncertainty about the first attempt

Idempotence matters most when the connection fails before the client reads a response. The server may have applied the request. It may have received nothing. The response may have been lost after a commit. Retrying an idempotent request is reasonable because repeating it should reach the same intended effect even if the first attempt succeeded.

Reasonable is not unlimited. RFC 9110 says a client should not automatically retry a non-idempotent method unless it knows the request is idempotent for that resource or can determine that the original was never applied. A proxy must not automatically retry non-idempotent requests. A client should not automatically retry a failed automatic retry.

The method is one input to a recovery decision. The client also needs the target, connection failure point, application contract, request content, preconditions and any deduplication identifier. “PUT is idempotent” cannot justify a blind loop. “POST is non-idempotent” does not forbid a resource-specific retry when the application has a stable operation key and a status endpoint.

This is where Running-Code Primacy is useful. The meaningful evidence is not an institutional label attached to a method. It is the behavior that independent participants can verify: whether duplicate attempts converge, whether the committed operation can be queried, and whether side effects remain bounded.

Preconditions protect a version, not a principal

Conditional headers refine a method without contradicting it. If-Match can require the current selected representation to carry a known entity tag before a state-changing request is applied. If the condition fails, the server does not perform the requested method and normally returns 412. This prevents an editor from overwriting a version changed by someone else.

The validator does not establish who the editor is or whether that editor is allowed to write. A leaked ETag is not a bearer credential. A valid credential does not make a stale ETag current. The server should evaluate both authorization and the resource precondition, preserving the reason for each refusal.

On uncertain retry, the precondition can also expose the outcome. If the requested change already appears to have been applied, RFC 9110 allows a success response in bounded circumstances, while warning about similar uncoordinated writers. A resource used as a nonatomic increment needs stricter treatment than a replacement of a known document state.

The clean chain is principal, permission, resource version, requested intention, application and result. A single green response cannot reconstruct that chain after the fact unless the system records it.

QUERY shows why a small vocabulary can still evolve

In June 2026, RFC 10008 defined QUERY. Its authors are Julian Reschke, James Snell and Mike Bishop, not Fielding. QUERY carries request content like POST but declares a safe, idempotent query. IANA now records it with Safe and Idempotent both set to yes.

The problem is visibility. Applications often send a complex read-only query in a POST body because a URI is too long or exposes query data in logs and bookmarks. Without resource-specific knowledge, a generic component sees POST and cannot know that the operation is safe or repeatable. QUERY makes that intention public while leaving the target to define the query content and decide whether to support it.

Registration does not deploy the method. It does not make a server implement it, a gateway forward it or a principal entitled to use it. It gives independent components a shared meaning if they adopt it. That is voluntary technical coordination at its most useful: a new common word reduces private inference while local acceptance remains visible.

The IANA registry should be read as a vocabulary ledger. Its Safe and Idempotent columns are compact behavioral declarations backed by specifications. They are not access-control lists.

Fielding's contribution is an interface boundary, not ownership

The IETF Datatracker reviewed on 31 August 2026 lists Roy T. Fielding as Senior Principal Scientist at Adobe, co-founder of The Apache Software Foundation, author of the REST architectural style and contributor to HTTP, URI and URI Templates. It lists 18 RFCs and an HTTP Directorate reviewer role. UC Irvine records his degrees and the Web, REST and Apache contributions for which he is known.

His dissertation explains the uniform interface as a REST constraint. Standardization improves visibility and reuse across network components; it also trades away some application-specific efficiency. The method vocabulary is a direct example of that bargain. A small set of common semantics lets intermediaries understand intent without seeing inside the application.

The attribution must remain bounded. RFC 9110 has three editors: Fielding, Mark Nottingham and Julian Reschke. HTTP is collective, revised work. Current implementations make their own decisions. RFC 10008 belongs to its named authors. Fielding's signature makes a contribution traceable; it does not give him ownership of the protocol or authority over every target.

That boundary strengthens the article's thesis. A standard can coordinate intention without becoming the source of permission. An editor can shape the common language without becoming its sovereign.

Replace the verb shortcut with an operation receipt

For every sensitive or automatically retried operation, record the method and target first. Then record the authenticated principal, credential scope, resource's supported-method decision, authorization policy and version, relevant ETag or other precondition, request content hash and intended effect.

If failure occurs, add the last confirmed transmission point, whether the first attempt may have been applied, the application idempotency key or convergence proof, who initiated the retry, the trigger, attempt count and backoff. Finish with the response, resulting resource state, downstream effects, compensations and any irreversible consequence.

This receipt keeps one short token in its proper place. The method tells independent components what the client means to ask. The resource says whether it understands. Authorization says whether this principal may ask it here. Preconditions say whether the state is still the one the request assumed. Retry evidence says whether another attempt is justified. Observed state says what actually happened.

The uniform interface works because those questions can join without becoming one question. A method names an intention. It does not confer a permission.

Sources