REST APIを開発していると、レスポンスに本文を返す必要がない操作が存在します。そのような場合に使用されるのがステータスコード204です。
「204 No Content」は処理が成功したものの、クライアントに返すべきコンテンツが存在しないことを示す成功コードです。
本記事では、ステータスコード204の意味と具体的な使用場面、200との使い分け、そしてAPI設計における活用方法まで詳しく解説します。
シンプルで使いやすいAPIを設計したいエンジニアにとって必ず役立つ内容でしょう。
ステータスコード204（No Content）とは？基本的な意味と役割
それではまず、ステータスコード204の基本的な定義と、HTTP通信における役割について解説していきます。
「204 No Content」はリクエストが正常に処理され、サーバーが返すべきコンテンツが存在しない場合に使用するHTTP成功コードです。
200（OK）と同様に処理成功を示しますが、204ではレスポンスボディに何も含まれないという点が大きな違いです。
204 No Contentの特徴
処理成功：リクエストは正常に処理されている
ボディなし：レスポンスボディは空（含めてはいけない）
画面遷移なし：ブラウザは現在のページを維持し、リロードしない
主な用途：DELETE・PUT・PATCH操作の成功時など
204が使われる主な場面
204が最もよく使われる場面はリソースの削除（DELETEメソッド）の成功時です。
リソースを削除した後、クライアントに返すべきデータは存在しないため、空のレスポンスと204を返すことが標準的な実装です。
PUTやPATCHによる更新でも、更新後のリソースをレスポンスに含める必要がない場合は204を返すことができるでしょう。
ブラウザの挙動と204
ブラウザが204レスポンスを受け取った場合、フォームの送信結果であっても現在表示しているページをリロードせずに維持します。
これは201や200の場合にブラウザが新しいページへ遷移する可能性があるのとは異なる挙動です。
AJAX（Fetch API・Axios）などを使ったリクエストでは、204の場合はレスポンスボディを解析しようとするとエラーになる可能性があるため、ステータスコードをチェックしてから処理を分岐する実装が必要でしょう。
204と200の使い分けとREST API設計のベストプラクティス
続いては、204と200の適切な使い分けとREST API設計における活用方法を確認していきます。
DELETE操作での204の使い方
RESTful APIの設計ではDELETEリクエストの成功時に204を返すことが一般的なベストプラクティスです。
削除されたリソースのデータをレスポンスに含める場合は200を返すことも許容されますが、削除後にクライアントがそのデータを必要としないケースでは204がよりクリーンな実装です。
204レスポンスを受け取ったクライアントは削除成功として処理し、UIからそのリソースを削除する実装が一般的でしょう。
PUTとPATCH操作での204の使い方
リソースの更新（PUTまたはPATCH）でも、更新後のリソースを返す必要がない場合は204を返すことができます。
更新後のリソースの確認が必要なUI・APIでは200と更新後のリソースデータを返し、確認が不要なシンプルな更新操作では204を返す設計が合理的です。
APIの利用者が更新後データを必要とするかどうかを設計段階で検討し、一貫した方針でコードを使い分けることが重要でしょう。
| 操作 | 推奨コード | レスポンスボディ | 用途例 |
|---|---|---|---|
| GET（取得成功） | 200 | リソースデータ | ユーザー情報の取得 |
| POST（作成成功） | 201 | 作成されたリソース | ユーザーの新規作成 |
| PUT/PATCH（更新） | 200 または 204 | 更新後データ または なし | プロフィールの更新 |
| DELETE（削除） | 204 | なし | ユーザーの削除 |
クライアント実装での204の処理
クライアント実装では204レスポンスの場合にレスポンスボディの解析を試みないよう、ステータスコードのチェックを先に行う実装が必要です。
JavaScriptのFetch APIでは「if (response.status === 204) return; const data = await response.json();」のような形で204とボディあり（200など）を分けて処理します。
Axiosなどのライブラリでも同様に204の場合はレスポンスデータの処理をスキップする実装を徹底することが重要でしょう。
204レスポンスの実装方法と注意点
続いては、サーバー側での204レスポンスの実装方法と、実装時の注意点を確認していきます。
主要フレームワークでの204の返し方
ExpressではJavaScriptで「res.status(204).send()」、Laravelでは「return response()->noContent()」、DjangoではPythonで「return HttpResponse(status=204)」のように実装します。
FastAPI（Python）では「return Response(status_code=204)」またはルーターデコレータに「status_code=204」を指定することで204を返すことができます。
フレームワークによってはNo Contentを返す専用メソッドが用意されているため、コードの可読性向上のためにそれらを積極的に活用するとよいでしょう。
204とContent-Lengthヘッダーの扱い
HTTP仕様上、204レスポンスはレスポンスボディを含めてはならないとされており、Content-Lengthヘッダーも0またはヘッダー自体を省略することが適切です。
一部のフレームワークでは204を返す際に自動的にContent-Lengthを「0」に設定しますが、意図せずボディが含まれてしまうと一部のクライアントで予期しない動作が発生する可能性があります。
レスポンスヘッダーを明示的に確認し、204の際にボディが含まれていないことをテストで検証することが重要でしょう。
OPTIONSリクエストへの204の使用
CORSプリフライトリクエスト（OPTIONSメソッド）に対するレスポンスとしても204がよく使用されます。
ブラウザが実際のAPIリクエストの前に送信するOPTIONSリクエストに対し、CORSを許可するヘッダーとともに204を返すことで、プリフライトチェックを通過させることができます。
CORSの設定を行うWebフレームワークの多くはOPTIONSへのレスポンスとして自動的に204を返す実装を採用しているでしょう。
まとめ
ステータスコード204（No Content）はリクエストが成功したがクライアントへ返すコンテンツがない場合に使用する成功コードであり、DELETEの成功やデータを返さないPUT/PATCH操作に適しています。
200との使い分けを明確にすることで、APIの意図が利用者に伝わりやすくなり、クライアント実装もシンプルになります。
一貫したHTTPステータスコードの使用はAPIの品質を高め、開発チーム全体の生産性向上につながるでしょう。
