Webサービスを利用する際、ブラウザとサーバーの間では常にHTTP通信が行われており、その結果はステータスコードという数値で表現されます。
中でもステータスコード200はHTTP通信が成功したことを示す最も基本的なコードであり、Webの世界で最も頻繁に登場するステータスコードです。
本記事では、ステータスコード200の意味と仕組み、レスポンスボディとの関係、そしてAPI設計における活用方法まで詳しく解説します。
Web開発を学ぶ方にとって基礎となる知識ですので、ぜひ理解を深めていただければ幸いです。
ステータスコード200（OK）とは？基本的な意味と定義
それではまず、ステータスコード200の基本的な意味とHTTP通信における役割について解説していきます。
「200 OK」はHTTPリクエストが正常に処理され、リクエストされた情報がレスポンスに含まれていることを示す成功コードです。
ブラウザでWebページを正常に表示できる場合、裏側では200のステータスコードが返されており、これがWeb通信の「正常な状態」を示す基準となっています。
ステータスコード200の特徴
意味：リクエストが成功し、レスポンスにデータが含まれている
レスポンスボディ：要求されたコンテンツ（HTML・JSON・画像など）が含まれる
適用範囲：GETリクエストの成功・PUTによる更新成功・POSTによるデータ取得成功など
キャッシュ：Cache-Controlヘッダーの設定によってキャッシュが可能
200レスポンスの構造
200レスポンスはステータスライン（HTTP/1.1 200 OK）・レスポンスヘッダー・空行・レスポンスボディという構造で構成されています。
レスポンスヘッダーにはContent-Type（レスポンスのデータ形式）・Content-Length（ボディのバイト数）・Cache-Control（キャッシュ設定）などの重要な情報が含まれます。
レスポンスボディにはHTMLコード・JSONデータ・画像データなど、リクエストに対応したコンテンツが格納されているでしょう。
200が返される主なシーン
GETリクエストでWebページのHTMLやAPIのデータを正常に取得した場合、PUTやPATCHリクエストでリソースを更新した際の確認レスポンス、POSTリクエストで検索やデータ取得を行った場合など様々な場面で200が返されます。
ただしPOSTでの新規リソース作成には201（Created）を、削除成功でレスポンスボディがない場合には204（No Content）を使うことが、より適切なAPI設計といえるでしょう。
200は最も汎用的な成功コードであるため、迷った場合には200を返すことが一般的な判断基準となります。
200レスポンスとレスポンスボディの関係
続いては、200レスポンスにおけるレスポンスボディの役割と、Content-Typeの重要性を確認していきます。
Content-Typeとレスポンスボディの形式
200レスポンスのボディに含まれるデータの形式は、Content-Typeヘッダーで宣言されます。
HTMLページを返す場合は「text/html; charset=UTF-8」、JSONデータを返す場合は「application/json」、画像を返す場合は「image/jpeg」や「image/png」が使用されます。
Content-Typeが正確に設定されていないと、ブラウザやクライアントがデータを正しく解釈できない可能性があるでしょう。
| コンテンツの種類 | Content-Typeの値 |
|---|---|
| HTMLページ | text/html; charset=UTF-8 |
| JSONデータ | application/json |
| XMLデータ | application/xml |
| テキスト | text/plain; charset=UTF-8 |
| JPEG画像 | image/jpeg |
| PDFファイル | application/pdf |
GETリクエストへの200レスポンス
GETリクエストは情報を取得するためのHTTPメソッドであり、成功した場合は必ずレスポンスボディにリクエストされたデータが含まれた200が返されます。
Webページへのアクセス・APIからのデータ取得・画像ファイルへのアクセスなど、最も一般的なHTTP通信パターンで200が使用されるでしょう。
ブラウザはGETの200レスポンスを受け取るとContent-Typeに基づいてボディを解釈し、画面上にページを表示します。
200レスポンスのキャッシュ制御
200レスポンスはCache-Controlヘッダーによってキャッシュの動作を細かく制御できます。
「Cache-Control: max-age=3600」と設定すると1時間のキャッシュが許可され、同じリソースへの再アクセス時にブラウザはサーバーへ再リクエストせずにキャッシュを利用します。
動的なデータを返すAPIでは「Cache-Control: no-cache」や「Cache-Control: no-store」を設定して常に最新データを取得させる制御が重要でしょう。
REST APIにおける200の適切な使い方
続いては、REST APIの設計における200の正しい使い方と他の2xx系コードとの使い分けを確認していきます。
200・201・204の使い分け
REST APIの設計では操作の内容に応じて適切な2xx系コードを選択することがAPIの品質向上につながります。
リソースの取得（GET）・更新（PUT/PATCH）・検索（POST）の成功には200を、新規リソースの作成（POST）成功には201を、削除（DELETE）成功でレスポンスボディがない場合には204を使用することが一般的なベストプラクティスです。
これらを正確に使い分けることでAPIクライアントが処理結果を正確に判断できるようになり、より使いやすいAPIの設計が実現できるでしょう。
200レスポンスのボディ設計
JSON APIのレスポンスボディ設計では、操作の結果データとメタ情報（ページネーション情報・リクエストIDなど）を一貫した構造で返すことが重要です。
「data」キーに主要なレスポンスデータを、「meta」キーに補助的な情報を格納するような一貫したレスポンス構造を定義することで、クライアントの実装を単純化できます。
エラーが発生した場合に200ではなく適切なエラーコード（400・404・500など）を返すことも、優れたAPI設計の基本でしょう。
HTTPメソッド別の200レスポンスの使い方
GETはリソースの取得に使用し、成功した場合は取得したリソースのデータを含む200を返します。
PUTはリソースの完全更新に使用し、更新後のリソースデータを含む200か、ボディなしの204を返すことが一般的です。
PATCHは部分更新に使用し、更新後のリソースデータを含む200を返すのが標準的な設計でしょう。
まとめ
ステータスコード200（OK）はHTTPリクエストが正常に処理され、レスポンスボディにリクエストされたデータが含まれていることを示す最も基本的な成功コードです。
Content-Typeによるレスポンス形式の正確な宣言・Cache-Controlによるキャッシュ制御・REST APIにおける201・204との適切な使い分けを理解することで、Web開発の品質が向上します。
200の意味と仕組みを正確に理解することは、Web通信の基礎を学ぶ上での重要な第一歩となるでしょう。
