ステータスコード201とは？200との違いも！（Created：意味：レスポンス：使い方など）

ステータスコード201とは？200との違いも！（Created：意味：レスポンス：使い方など）

WebサイトやAPIを開発していると、HTTPレスポンスで201 Createdというステータスコードを目にすることがあります。

200 OKと似た成功のコードに見えますが、両者はサーバー側で行われた処理と、クライアントへ伝えるべき結果が異なります。

登録フォーム、会員作成、注文受付、ファイルアップロードなどでは、適切なコードを返すことがAPIの分かりやすさや保守性につながります。

この記事では、201の意味、200との違い、レスポンスヘッダーの扱い、実装時の注意点を初心者にも分かる形で整理します。

ステータスコード201の意味と結論

それではまずステータスコード201について解説していきます。

Createdが示すリソース作成の完了

HTTPステータスコード201は、クライアントからのリクエストを受けて、サーバーが新しいリソースを正常に作成したことを表す成功レスポンスです。

Createdは作成済みという意味であり、単に処理が受け付けられた段階ではなく、新しいデータがサーバー上で利用できる状態になったことを伝えます。

たとえばユーザー登録APIへPOSTリクエストを送信し、新しいユーザーIDを持つレコードがデータベースに保存された場合、201を返す場面が代表例です。

商品、予約、コメント、問い合わせ、画像、プロジェクトなど、識別できる新規データを生み出す操作と相性がよいコードでしょう。

ここでいうリソースは、URLによって参照できる対象だけに限定されません。

APIの設計上、サーバーが管理する独立したデータとして扱われるなら、作成対象として考えられます。

201を返す代表的なHTTPメソッド

201はPOSTメソッドと組み合わせて使われることが多いものの、POST専用のコードではありません。

新規作成という結果が生じるなら、PUTなどで返される可能性もあります。

POSTは、コレクションURLに対して新しい要素を追加する用途で使われやすいメソッドです。

たとえばPOST /usersにユーザー情報を送信し、サーバーが/users/123という新しい対象を作る構成が考えられます。

PUTは指定したURLの対象を作成または置換する性質を持ちます。

まだ存在しないPUT /profiles/taroへのリクエストによってプロフィールが初めて作られた場合には、201が自然な選択になるでしょう。

メソッド	201が使われる場面	具体例
POST	コレクション内に新規要素を追加した場合	会員登録、注文作成、コメント投稿
PUT	指定URLのリソースが存在せず新規作成された場合	固定IDの設定情報作成
PATCH	通常は更新が中心だが、設計によって新規作成を許可する場合	条件付きのプロフィール生成

成功コードの中での201の位置付け

HTTPステータスコードは先頭の数字によって大まかな意味を分類しています。

2から始まるコードは、リクエストが正常に処理されたことを示す成功のグループです。

そのなかでも200は一般的な成功、201は作成成功、204は返す本文がない成功というように、結果の違いを細かく表現します。

成功なら常に200を返す必要はありません。

操作の結果に最も合うコードを選ぶことで、フロントエンド、モバイルアプリ、外部連携先がレスポンスを機械的に扱いやすくなります。

ログや監視ツールを確認するときにも、作成処理と更新処理の傾向を分けて追いやすくなる利点があります。

200との違いと使い分け

続いては200との違いを確認していきます。

200 OKが表す一般的な成功

200 OKは、リクエストが成功したことを示す最も基本的なHTTPステータスコードです。

GETで商品情報を取得できた場合、検索結果を返せた場合、既存データの更新が完了した場合など、幅広い処理で利用されます。

ただし200という数字だけでは、新しいリソースが作成されたのか、すでにある情報を取得したのか、内容を変更したのかまでは読み取れません。

一方の201は、成功の詳細として作成結果を明示します。

この違いは小さく見えても、REST APIを長く運用するほど重要になります。

比較項目	200 OK	201 Created
基本の意味	リクエストの成功	新規リソースの作成成功
主な用途	取得、検索、更新、通常の処理成功	登録、追加、生成
Locationヘッダー	通常は必須ではない	作成先を示す用途で推奨される
レスポンス本文	取得結果や処理結果を返しやすい	作成済みデータや識別子を返しやすい
利用者が受け取る印象	処理は問題なく終わった	新しい対象が利用可能になった

登録処理で201を選ぶ理由

会員登録や注文作成のような処理で201を返すと、クライアントは新規作成の成功を明確に認識できます。

作成後に詳細画面へ移動したい場合や、続けて関連データを登録したい場合にも、返却されたIDやURLをそのまま利用できます。

たとえば注文APIが200を返しても動作自体は可能ですが、作成なのか既存注文への操作なのかをレスポンスコードから判断しにくくなります。

作成という業務上の出来事をHTTPの意味に正しく対応させることが、分かりやすいインターフェースにつながります。

複数人でAPIを開発するチームでは、設計書を読まなくてもコードの意図を推測しやすい点も見逃せません。

同じPOSTでも200になるケース

POSTリクエストだから必ず201になるわけではありません。

たとえば検索条件をPOSTで送って検索結果を取得するAPIでは、新規リソースが作成されないため200が適しています。

決済実行APIでも、外部サービスへ依頼を送っただけで、注文や決済記録がまだ確定していないなら、処理内容に応じて200や202を検討します。

既存ユーザーに対してログイン認証を行い、アクセストークンを返す処理も、一般には200が選ばれます。

判断の基準はHTTPメソッドではなく、サーバーが新しいリソースを作成したかどうかです。

この視点を持つと、ステータスコード選びで迷いにくくなるでしょう。

Createdレスポンスの構成要素

続いてはCreatedレスポンスの内容を確認していきます。

Locationヘッダーの役割

201 Createdを返すときには、作成されたリソースのURIをLocationヘッダーに含める設計が推奨されます。

URIはWeb上の対象を識別する住所のようなもので、クライアントはこの値を使って作成結果を取得できます。

たとえば新しいタスクが作られたなら、Locationに/api/tasks/456のようなパスを返します。

レスポンス本文だけにIDを入れる方法もありますが、標準的なヘッダーに作成先を示すことで意味が伝わりやすくなります。

特に外部公開APIでは、利用者ごとに実装言語や開発経験が異なるため、慣例に沿った応答が親切です。

レスポンス本文に含める情報

201のレスポンス本文には、作成直後のリソース全体、識別子だけ、作成結果の要約などを含められます。

どこまで返すかは、通信量、セキュリティ、クライアント側の使い方によって決まります。

登録後すぐに画面へ表示する情報が必要なら、作成されたデータを本文に含めると、追加のGETリクエストを減らせます。

一方で、機密情報や内部用の項目まで返してしまわないよう、公開するフィールドは慎重に選ぶ必要があります。

パスワード、認証トークン、内部フラグなどは作成成功時であっても不用意に返さないことが大切です。

APIのレスポンス形式を統一しておくと、利用側の例外処理も簡潔になります。

レスポンス本文を省略する場合

201であっても、必ず大きなレスポンス本文を返す必要はありません。

作成先のLocationだけで十分な場合や、クライアントが後から詳細取得を行う設計では、本文を小さく抑えることができます。

ただし、本文を完全に空にするかどうかは、利用者の実装負荷も踏まえて決めるべきです。

作成後に必要なIDが本文にも含まれていれば、画面遷移や状態更新を実装しやすいケースがあります。

大量データの登録では、受け付けた件数、成功件数、失敗件数、生成された識別子を返す設計も有効です。

重要なのは、レスポンスコード、ヘッダー、本文の内容が互いに矛盾しないことです。

API実装における201の使い方

続いてはAPI実装における使い方を確認していきます。

ユーザー登録APIの設計

ユーザー登録では、入力値の検証、メールアドレスの重複確認、パスワードの安全なハッシュ化、データ保存といった処理が行われます。

すべてが成功して新しいユーザーが確定した時点で、201 Createdを返す流れが基本です。

もしメールアドレスがすでに登録済みなら、作成は成功していないため201にはなりません。

重複という状態を伝えるには409 Conflict、入力内容に問題がある場合には400 Bad Requestや422 Unprocessable Contentなど、APIの方針に合うコードを選びます。

成功と失敗を明確に分けることで、画面には適切なメッセージを出せます。

201を返す前に、データが実際に永続化されていることも確認したいポイントです。

ファイルアップロードAPIの扱い

画像やPDFなどのアップロードも、新しいファイルリソースを管理するなら201の対象になります。

アップロード完了後にファイルID、閲覧用URL、MIMEタイプ、サイズ、作成日時を返すと、フロントエンドは直後にプレビューを表示できます。

ただし、ウイルススキャン、画像変換、サムネイル作成などが非同期で続く場合には注意が必要です。

元ファイル自体は作られたものの、利用可能な状態になるまで待つ必要があるなら、ステータスや本文の状態値を設計に含めます。

処理の完了を待たずに受け付けだけを返すケースでは、202 Acceptedの方が意味に合うこともあります。

作成完了と処理受付を混同しないことが、ユーザー体験の混乱を防ぎます。

冪等性を意識した重複作成の防止

通信障害やタイムアウトが起きると、クライアントは同じPOSTリクエストを再送することがあります。

最初の処理で作成済みなのに、再送によって同じ注文や予約が二重に作られると、大きなトラブルになりかねません。

決済、注文、請求などの重要な作成APIでは、冪等性キーを受け取って重複実行を防ぐ対策がよく行われます。

同じキーで再送された場合には、最初に作成した結果を返すか、すでに処理済みであることを定義に沿って知らせます。

このときも、単に201を返すだけで終わらせず、リクエストIDや作成済みリソースの参照先を記録しておくと調査しやすくなります。

201利用時の注意点と関連コード

続いては201利用時の注意点と関連コードを確認していきます。

202と201の判断基準

201と混同されやすいコードに202 Acceptedがあります。

202はリクエストを受け付けたことを示しますが、処理が完了したことまでは保証しません。

動画変換、集計処理、大量インポートのように時間がかかる処理では、ジョブを受け付けて202を返し、完了後に結果を確認できる設計が適しています。

一方、作成対象がすでに完成し、クライアントが利用できるなら201を選びます。

即時に作成完了したのか、後続処理を待つのかが両者を選ぶ大きな基準です。

ステータスコード	意味	適した場面
200 OK	一般的な成功	取得、検索、認証、既存データの更新
201 Created	新規作成の成功	会員、注文、投稿、ファイルの作成
202 Accepted	処理の受付	非同期変換、バックグラウンドジョブ
204 No Content	本文なしの成功	削除、応答不要な更新
409 Conflict	現在の状態との競合	重複登録、楽観ロックの競合

既存データ更新で201を返さない注意点

既存のリソースを編集しただけなら、通常は200または204を返します。

たとえばユーザーIDが123の表示名を変更した場合、対象はすでに存在しているため、新規作成とはいえません。

更新後のユーザー情報を返すなら200、本文を返さないなら204という使い分けが一般的です。

ただしPUTで指定URLに対象が存在せず、その呼び出しによって初めて作成されたなら201になる余地があります。

API仕様書には、存在時と未存在時で返すコードが変わるかどうかを明記しておくとよいでしょう。

クライアント側が成功コードを幅広く受け入れる実装にしておくことも、連携時の安定性に役立ちます。

キャッシュとセキュリティの確認

201のレスポンスには、個人情報や業務上の重要情報が含まれる場合があります。

ブラウザや中継サーバーに保存されることが望ましくない内容なら、キャッシュ制御ヘッダーを適切に設定する必要があります。

認証済みユーザーにだけ見せるデータは、アクセス制御の確認も欠かせません。

Locationヘッダーに予測可能な連番IDを含める設計では、URLを直接指定した不正閲覧が起きないよう、取得API側でも権限を検証します。

201は作成の成功を示すコードであり、認可や情報公開の安全性を保証するものではありません。

レスポンス設計とセキュリティ設計を別々にせず、同時に確認する姿勢が重要です。

ステータスコード201のまとめ

ステータスコード201 Createdは、HTTPリクエストの成功と、新しいリソースの作成完了を同時に伝えるコードです。

200 OKとの違いは、単なる成功ではなく、作成という結果を明示する点にあります。

ユーザー登録、注文作成、記事投稿、ファイルアップロードなどでは、201を返すことでAPIの意図を伝えやすくなります。

作成された対象を案内するLocationヘッダーや、必要最小限のレスポンス本文を用意すると、クライアントは次の処理へ進みやすくなるでしょう。

一方で、非同期処理の受付には202、既存データの更新には200または204など、結果に応じた使い分けが必要です。

HTTPステータスコードは数字を返すだけの仕組みではなく、サーバーとクライアントの認識をそろえるための共通言語と考えると理解が深まります。

APIを設計するときは、実際に何が作られたのか、いつ利用できるのか、作成先をどう案内するのかを整理したうえで、201 Createdを活用してください。