HTTP メソッドリファレンス
実際に API 設計を形作る 4 つの特性 — 安全 (サーバー側の副作用なし)、冪等 (N 回繰り返した同じ最終状態)、キャッシュ可能 (レスポンスを再利用可能)、ボディを持つ (リクエストとレスポンス) — をメソッドごとに収集し、それぞれが適切な場合の 1 行の要約を含む。
Retrieve a representation of a resource. Should have no side effects.
- 安全
- はい
- 冪等
- はい
- キャッシュ可能
- はい
- Req body
- いいえ
- Res body
- はい
Like GET but with no response body. Used to inspect headers (size, ETag, Last-Modified).
- 安全
- はい
- 冪等
- はい
- キャッシュ可能
- はい
- Req body
- いいえ
- Res body
- いいえ
Submit data to the server — create a new resource, send a form, or trigger a side-effecting action. Cacheable only when explicit Cache-Control / Expires headers permit.
- 安全
- いいえ
- 冪等
- いいえ
- キャッシュ可能
- 条件付き
- Req body
- はい
- Res body
- はい
Replace the target resource entirely with the request payload. Calling it twice gives the same result as once.
- 安全
- いいえ
- 冪等
- はい
- キャッシュ可能
- いいえ
- Req body
- はい
- Res body
- はい
Remove the target resource. Idempotent in the same sense as PUT — deleting an already-gone resource still ends with the same state.
- 安全
- いいえ
- 冪等
- はい
- キャッシュ可能
- いいえ
- Req body
- 条件付き
- Res body
- はい
Apply a partial update to the resource. RFC 5789 leaves the patch format up to the API — JSON Patch (RFC 6902) and JSON Merge Patch (RFC 7396) are the common choices.
- 安全
- いいえ
- 冪等
- いいえ
- キャッシュ可能
- いいえ
- Req body
- はい
- Res body
- はい
Ask what the server supports for the target — methods, CORS preflight, accepted Content-Types. The response usually carries an Allow header.
- 安全
- はい
- 冪等
- はい
- キャッシュ可能
- いいえ
- Req body
- いいえ
- Res body
- はい
Echo back the request as the server sees it after proxies. Usually disabled in production for security (Cross-Site Tracing).
- 安全
- はい
- 冪等
- はい
- キャッシュ可能
- いいえ
- Req body
- いいえ
- Res body
- はい
Establish a tunnel to the server, used by HTTP proxies for HTTPS. The client and server exchange raw bytes after the proxy accepts.
- 安全
- いいえ
- 冪等
- いいえ
- キャッシュ可能
- いいえ
- Req body
- いいえ
- Res body
- いいえ
「条件付き」は、明示的なヘッダ (POST の Cache-Control、DELETE のボディ) のもとでのみ特性が成立することを意味する。
使い方
- メソッド名 (`patch`) またはキーワード (`cache`、`tunnel`) を入力してフィルタ。
- メソッドごとのカードを読む：上に説明、その下に 5 つの特性ドット。
- コピーをクリックして fetch コールや curl コマンドにメソッドを入れる。
よくある質問
- POST が同じことをできるのに、なぜ PATCH には独自のメソッドがある？
- セマンティクス。PATCH は「この部分的な diff を適用」を意味する；POST は「このペイロードを作成または処理する」。パッチ形式がよく設計されていれば、PATCH を 2 回呼ぶと 1 回呼んだのと同じリソース状態になる；その冪等性の保証は追加の動詞の価値がある。
- POST は本当にキャッシュ可能？
- 条件付き — RFC 9111 §3 はレスポンスが明示的な `Cache-Control` / `Expires` ヘッダを持つときに POST レスポンスをキャッシュすることを許可する。実際にはほとんど誰もこれを行わないので、ほとんどのキャッシュは POST をキャッシュ不可として扱う。
- 二回目が404を返すなら、DELETEは冪等ではないのでは?
- 冪等のままです。冪等性は要求のあとのサーバーの状態を指すもので、返ってくるステータスコードのことではありません。一度削除すれば資源は消え、もう一度削除しても消えたままです。終わりの状態は同じで、404はすでに真であった事実を伝えているにすぎません。一度目に200を返し、変化なくもう一度200を返すPUTも同じ理屈です。
- 検索の条件がURLに収まりません。POSTに変えるべき?
- 検索を正しく言い表すのはGETです。安全で、キャッシュでき、共有もできます。ただしサーバーやプロキシやログにはURLの実用的な長さの上限があり、URLに載せた条件は経路上のすべてのアクセスログに書き残されます。条件が本当に大きい、あるいは扱いに注意が要る場合はPOSTが現実的な答えです。その代わりキャッシュと、同僚に送れるリンクを失います。
関連ツール
HTTP ヘッダリファレンス
標準 HTTP リクエスト・レスポンス・CORS・キャッシュ・セキュリティ・Cookie ヘッダ 約50個の検索可能リファレンス。
HTTP ステータスコード リファレンス
1xx-5xx の全 HTTP ステータスコードを検索 — 概要・RFC・使い時・よくある落とし穴付き。
Base64 エンコーダー / デコーダー
テキストを Base64 にエンコード、または Base64 をテキストにデコード。
HTTP Cookie パーサー
`Cookie:` リクエストヘッダや `Set-Cookie:` レスポンスヘッダを貼り付けて、各クッキーの名前、値、属性、警告を表示。
ASCII コード表
256 行の ASCII / 拡張 ASCII 表 — 10進・16進・8進・2進、制御文字の名前まで。検索・コピー対応。
MIME タイプ検索
ファイル拡張子から MIME タイプを検索（または逆引き）。各タイプの用途も解説。