HTTPメソッド × ステータスコード早見表

「このAPI、成功時は201？204？」と迷ったときに参照できる表です。RFC 9110の意味づけに沿って、実務でよく出る組み合わせを整理しました。

成功パターン

2xxは成功を示します。表には再検証で使う3xxの304も併記しています。HEADの応答、204、304には本文を付けられません。202は処理完了を保証しません。

メソッド	主な成功コード	使いどころ
GET/HEAD	200 OK / 304 Not Modified	取得。条件付きGET/HEADで変更がなければ304。HEADは200でも本文なし。GETの有効な部分取得では206も使う。
POST	201 Created / 202 Accepted / 200 OK	作成なら201＋Locationヘッダー。非同期受付なら202。既存リソース更新をPOSTで行うなら200も選択肢。
PUT	200 OK / 204 No Content / 201 Created	現在の表現を更新した成功は200または204。現在の表現がなく新規作成に成功した場合は201が必要（RFC 9110 §9.3.4）。
PATCH	200 OK / 204 No Content	更新の成功は200や204。作成可能なパッチ形式・APIでは201となる場合もある（RFC 5789）。
DELETE	200 OK / 204 No Content / 202 Accepted	完了して説明を返すなら200、本文なしなら204、未完了の受付なら202。再要求の404も冪等性と矛盾しない。
OPTIONS	204 No Content	通信可否の応答。CORSプレフライトで多用。

仕様に沿ったエラーを返すとクライアントが自動リトライやUXを組みやすくなります。

コード	典型メソッド	意味とヒント
400 Bad Request	全般	リクエスト形式エラー。ボディにエラー詳細を。
401 Unauthorized	全般	認証が必要。WWW-Authenticateヘッダーを返す。
403 Forbidden	全般	要求を理解したが実行を拒否。権限不足は一例で、認証済みであることは必須条件ではない。
404 Not Found	全般	現在の表現がない、または存在を明かさない。DELETEの再要求で返しても冪等性に反しない。
405 Method Not Allowed	全般	そのURIで未サポートのメソッド。Allowヘッダー必須（RFC 9110 15.5.6）。
409 Conflict	POST/PUT/PATCH/DELETE	競合（例: 重複キー、状態衝突）。ボディに解決策を書くと親切。
412 Precondition Failed	PUT/PATCH/DELETE	要求ヘッダーで指定された前提条件が不成立。ロック失敗全般のコードではない。
415 Unsupported Media Type	POST/PUT/PATCH	要求内容の形式やContent-Encodingなどが未対応。対応可能な形式を示すと良い。
422 Unprocessable Content	POST/PUT/PATCH	メディアタイプを理解し、構文も正しいが、内容の指示を処理できない。JSON構文の破損とは区別する（RFC 9110 §15.5.21）。
429 Too Many Requests	全般	レート制限（RFC 6585 §4）。Retry-Afterは任意で添えられる。応答はキャッシュ保存不可。
500/503	全般	サーバー内エラー / 一時的に利用不可。503ではRetry-Afterが有効。

コードとメソッドの相性を少し意識するだけで、クライアント実装がぐっと楽になります。

POSTで作成したらLocationヘッダーで新リソースURIを示す（RFC 9110 10.2.2）。
条件付きリクエスト（If-Match/If-None-Match）を併用し、412や304を正しく返すと中間キャッシュとも仲良くできる。
DELETEの再要求でコードが変わっても、意図した効果が同じなら冪等性を保てます。応答が失われた場合に備え、APIの状態確認方法を用意します。
意味の合う標準コードを使い、本文を返せる応答では問題の詳細を説明します。application/problem+json（RFC 9457）も利用できます。204にエラー詳細のJSONを付けてはいけません。

コードはメソッド名だけでなく、実際の処理結果と条件に合わせて選びます。安全性と冪等性、304・412と条件付きリクエストも合わせて確認してください。

< HTTPリクエストメソッドの使い分け条件付きリクエストとETag活用 >