Check whether an HTTP method is safe or idempotent

Classify a standard HTTP method by the safety and idempotency properties defined by HTTP semantics. Enter a method such as GET, POST, PUT, PATCH, or DELETE and receive normalized method text, separate Boolean results, and a concise combined classification. The checker recognizes the nine methods defined across the core HTTP semantics and PATCH specifications, ignores surrounding whitespace and letter case, and rejects unknown names instead of making assumptions about extension methods.

Distinguish safety from idempotency

Safety and idempotency describe different promises. A safe method is intended for information retrieval or communication options rather than a requested state change on the origin server. Idempotency is broader: it means that multiple identical requests have the same intended effect on the server as one such request. PUT and DELETE are idempotent even though they are not safe, because replacing a representation with the same representation again, or repeatedly requesting deletion of the same resource, does not introduce a new intended effect each time. GET, HEAD, OPTIONS, and TRACE are safe. HTTP semantics also define every safe method as idempotent, so those methods receive the combined `safe_and_idempotent` classification. The response exposes `safe` and `idempotent` separately so policy code does not need to infer one property from a label. It also returns a `classification` field for display, logging, or simple branching. These properties concern standardized request semantics, not whether a particular implementation is bug-free or free from incidental side effects.

Interpret retries correctly

Idempotency is especially useful when deciding whether an automated client may retry a request after a connection failure. For example, an initial DELETE can remove a resource and return success, while a later identical DELETE can report that the resource no longer exists; the intended server state is still the same. PUT is similarly idempotent when the repeated requests carry the same target and representation. A client might not know whether the server received the first request, so repeating an idempotent method preserves the request's intended effect. That does not guarantee identical response status codes or bodies. POST and PATCH are classified as neither safe nor idempotent by their general method definitions. A specific API can design an individual POST or PATCH operation to be retryable, perhaps through an idempotency key or conditional request, but that application-level contract does not change the default standardized property of the method itself. Use this result as a protocol baseline, then apply any stronger guarantees explicitly documented by the API you are calling.

Validate method names before applying policy

Guessing the properties of an extension method from its spelling could approve an unsafe retry or block a valid operation. If your system uses an extension method, consult the specification that registers or defines it and handle that method through an explicit policy. The algorithm performs no network request and never observes a live server, route implementation, cache, proxy, or request body. The checker accepts the standard method names CONNECT, DELETE, GET, HEAD, OPTIONS, PATCH, POST, PUT, and TRACE. Input is trimmed and converted to uppercase, so values such as ` get ` and `patch` are normalized without changing their meaning. Any other value produces an `invalid_input` error. This strict behavior matters because HTTP method tokens are extensible: WebDAV and other protocols define additional methods, and private APIs can introduce their own tokens. It is deterministic and suitable for linters, API documentation checks, retry middleware configuration, and browser-based learning tools.