Safe HTTP Methods — Read-Only Guarantees

What Makes a Method "Safe"?

An HTTP method is safe if it does not alter the state of the server. The request is purely read-only. GET, HEAD, OPTIONS, and TRACE are safe methods.

Safety Matrix

Method	Safe	Why
GET	Yes	Only retrieves data
HEAD	Yes	Same as GET, no body
OPTIONS	Yes	Describes capabilities
TRACE	Yes	Echoes request back
POST	No	Creates resources / triggers actions
PUT	No	Replaces resources
PATCH	No	Modifies resources
DELETE	No	Removes resources
CONNECT	No	Establishes tunnels

Why Safety Matters

Browsers rely on method safety for:

• Prefetching — Browsers may speculatively fetch <link rel="prefetch"> URLs using GET, knowing it will not cause side effects
• Back/forward cache — Cached GET responses can be reused when navigating history
• Crawlers — Search engines follow links (GET requests) without fear of modifying data

Proxies and CDNs leverage safety for:

• Caching — Safe methods are cacheable by default
• Retries — Safe requests can be retried on failure without consequences
• Connection pooling — Multiple safe requests can share connections freely

Common Mistakes

1. Using GET for state changes — GET /api/delete-user/42 violates the safety contract. A crawler following this link would delete the user.
2. Using POST for reads — While not harmful, it prevents caching and breaks browser navigation expectations.
3. Side effects in GET handlers — Logging a page view is borderline acceptable, but creating records or sending emails from a GET handler is a violation.

The Practical Rule

If a request only reads data, use GET or HEAD. If it changes data, use POST, PUT, PATCH, or DELETE. This keeps your API predictable for clients, proxies, and browsers.