HTTP メソッド Semantics

Core Methods

HTTP methods communicate the intent of a request and determine how caches and intermediaries handle it. Safe methods like GET and HEAD must not change server state, allowing caches and prefetchers to use them freely. Idempotent methods like PUT and DELETE produce the same effect regardless of how many times they are applied. Understanding these semantics is essential for building REST APIs that behave predictably under retries and caching.

GET

Retrieve resource, safe and idempotent

GET /users/1

POST

Create or perform action, not idempotent

POST /users

PUT

Replace resource at URI, idempotent

PUT /users/1

DELETE

Remove resource, idempotent

DELETE /users/1

PATCH

Partial modification, not idempotent

PATCH /users/1

Idempotency and Safety

Safety means the method is read-only and has no side effects, so calling it repeatedly has no observable consequence. Idempotency means repeated identical calls produce the same result as a single call, even if state changes. POST is neither safe nor idempotent, which is why retrying POST requests can create duplicate resources. Idempotency keys are a common pattern to make POST safe to retry by deduplicating on a client-supplied key.

Cacheability

Only safe methods are cacheable by default, which in practice means GET and HEAD. POST responses can be cached explicitly with Cache-Control but this is rare and error-prone. The cache key includes the method, URI, and selected request headers. Vary headers control which request headers participate in the key to avoid serving the wrong variant. Misunderstanding cacheability leads to stale data or, worse, caching of side-effecting operations.