Blog

ステータスコード201 Createdとは？APIの作成成功レスポンス

INEZA Felin-Michel

INEZA Felin-Michel

11 9月 2025

ステータスコード201 Createdとは？APIの作成成功レスポンス

ウェブ開発、API、またはサーバー通信に足を踏み入れるなら、HTTPステータスコードは日々の生活の一部となるでしょう。よく遭遇するHTTPレスポンスステータスコードの1つに「201 Created」があります。これは一見すると分かりやすいかもしれませんが、その意味、適切な使用法、および影響を理解することは、クリーンで信頼性の高いAPIとウェブアプリケーションを構築する上で大きな違いを生み出します。

このブログ記事では、201 Createdステータスコードとは何か、なぜそれが重要なのか、どのように正しく使用するか、そしてそれを取り巻くAPI設計のベストプラクティスについて探ります。APIを構築またはテストしている場合、201 Createdのようなレスポンスを検証するには強力なAPIプラットフォームが必要です。そこで登場するのがApidogです。無料で始められるAPIテストプラットフォームであるApidogを使えば、APIをリアルタイムで設計、モック、テスト、デバッグ、ドキュメント化できます。また、201 Createdを含むAPIワークフローを検証し、自動化することで、より高い信頼性と迅速なリリースを実現できます。そして最高の点は、Apidogを無料でダウンロードして、今日からステータスコードの実験を始められることです。

ボタン

それでは、HTTP 201 Createdステータスコードの目的、メカニズム、ベストプラクティスを探っていきましょう。

「成功」のその先へ：HTTPステータスコードのセマンティクス

HTTPステータスコードはクラスに分類されます。最も有名なのは、成功を示す2xxクラスです。しかし、成功の中にも異なる種類があります。

201 Createdの美しさはその具体性です。曖昧さをすべて排除します。201を受け取ったクライアントアプリケーションは、新しいリソースがサーバー上に存在することを100%確信できます。

HTTPステータスコード201 Createdとは？

HTTP 201 Createdステータスコードは、2xx Successファミリーの一部であり、以下のことを示します。

「リクエストは正常に完了し、新しいリソースの作成に成功しました。」

これは以下のことを示します。

簡単に言えば、クライアントが新しいユーザー、投稿、注文、ファイルなどの作成をサーバーに要求し（通常はPOSTまたはPUT）、サーバーがこの201レスポンスで作成が成功したことを確認します。

201は通常いつ返されますか？

最も一般的なシナリオは、サーバー上に新しいものを作成するPOSTリクエストです。

これらの場合、サーバーは201 Createdステータスとともに、新しいリソースの詳細（多くの場合、その一意の識別子またはURLを含む）を返します。

APIにとって201 Createdの使用が重要な理由

201ステータスコードを適切に使用することは、API開発者とユーザーにとって以下の点でメリットがあります。

完璧な201 Createdレスポンスの構造

201レスポンスは、単にステータスコードだけではありません。それはパッケージ取引です。真に適切に作成された201レスポンスには、3つの主要なコンポーネントが含まれています。

1. ステータスコード

最初で最も重要な部分は、ステータスラインそのものです。

HTTP/1.1 201 Created

これは直ちにクライアントの期待を設定します。

2. Locationヘッダー（最も重要な部分）

これは201レスポンスの目玉です。Locationヘッダーには、新しく作成されたリソースのURLが含まれている必要があります。

Location: /users/12345

または、より良いのは完全修飾URLです。

Location: <https://api.example.com/v1/users/12345>

なぜこれがそれほど重要なのでしょうか？クライアントは何かを作成したばかりですが、それがどこにあるのか知らないかもしれません。Locationヘッダーは決定的なパスを提供します。クライアントは、そのリソースに対する後続のすべてのGET、PUT、またはDELETEリクエストにこのURLを使用できます。これは、新しいリソースのアドレスが記載された「領収書」です。

3. レスポンスボディ

厳密には必須ではありませんが、新しく作成されたリソースの表現をレスポンスボディに含めることは、非常に強力な慣習でありベストプラクティスです。

クライアントがデータを作成するために送信したばかりなのに、なぜリソースを返すのでしょうか？いくつかの理由があります。

典型的なレスポンスボディは、新しいリソースのJSON表現になります。

{
  "id": 12345,
  "username": "johndoe",
  "email": "john.doe@example.com",
  "created_at": "2025-9-9T10:00:00Z",
  "updated_at": "2025-9-9T10:00:00Z"
}

201を正しく使用するメリット

201 Createdの例示シナリオ

いくつかの実用的な例を見てみましょう。

例1：新しいユーザーの作成

クライアントリクエスト：

POST /users HTTP/1.1
Host: api.example.com
Content-Type: application/json

{
  "name": "Alice",
  "email": "alice@example.com"
}

サーバーレスポンス：

HTTP/1.1 201 Created
Location: /users/101
Content-Type: application/json

{
  "id": 101,
  "name": "Alice",
  "email": "alice@example.com"
}

ここで、サーバーは明示的に述べています：「ユーザー101を作成しました。/users/101で見つけることができます。」

例2：ファイルのアップロード

画像をアップロードする場合：

POST /images

サーバーは以下で応答します：

HTTP/1.1 201 Created
Location: /images/42

これは、あなたのファイルが新しいリソースとして存在することを意味します。

例3：ブログ記事の作成

POST /posts

サーバー：

HTTP/1.1 201 Created
Location: /posts/567

実際の使用例

201 Created vs 200 OK vs 204 No Content: 違いは何ですか？

201が他の成功コードとどう異なるかを理解することは不可欠です。

ステータスコード 意味 使用時期
201 Created 新しいリソースが正常に作成されました 新しいデータを作成するPOSTまたはPUTリクエスト用
200 OK リクエストはレスポンスデータと共に成功しました 一般的な成功したGET、POSTなど用
204 No Content リクエストは成功しましたが、レスポンスボディがありません データが返されない成功したリクエスト用

201は新しいリソースの作成を意味し、200は一般的な成功を意味し、204は成功したが意図的にレスポンスコンテンツがないことを意味します。迷った場合は、後で新しいURLを指し示すことができるなら、201を使用してください。

201 Createdを使用する時期：完璧な適合

201 Createdステータスコードは、主に1つのシナリオで使用する必要があります。

新しいリソースの作成に成功したPOSTリクエストへの応答として。

いくつかの典型的な例を見てみましょう。

  1. ユーザー登録： POST /users -> 新しいユーザーを作成します。レスポンス：201 Created。
  2. データベースへのアイテム追加： POST /articles -> 新しいブログ記事を作成します。レスポンス：201 Created。
  3. ファイルのアップロード： POST /uploads -> サーバー上に新しいファイルリソースを作成します。レスポンス：201 Created。
  4. 注文の確定： POST /orders -> 新しい販売注文を作成します。レスポンス：201 Created。

それぞれの場合において、クライアントのアクションは直接的で明確な結果をもたらします。新しい、アクセス可能なリソースがユニークなURLに存在することになります。

異なる言語での201 Createdの実装方法

Node.js (Express)

app.post('/users', (req, res) => {
  const newUser = { id: 101, ...req.body };
  res.status(201).location(`/users/${newUser.id}`).json(newUser);
});

Python (Flask)

from flask import Flask, jsonify, request, make_response

app = Flask(__name__)

@app.route('/users', methods=['POST'])
def create_user():
    data = request.get_json()
    new_user = {"id": 101, **data}
    response = make_response(jsonify(new_user), 201)
    response.headers['Location'] = f"/users/{new_user['id']}"
    return response

Java (Spring Boot)

@PostMapping("/users")
public ResponseEntity<User> createUser(@RequestBody User user) {
    user.setId(101L);
    return ResponseEntity
        .created(URI.create("/users/" + user.getId()))
        .body(user);
}

アプリケーションで201 Createdを処理する方法

よくある間違いと悪い習慣

経験豊富な開発者でもこれを間違えることがあります。避けるべきことは次のとおりです。

  1. 作成に対して200 OKを返すこと：これは最も一般的な間違いです。間違いではありませんが、HTTPのセマンティクスを完全に活用できず、精度が低くなります。
  2. Locationヘッダーなしで201を返すこと：これはAPI設計の重大な過ちです。Locationヘッダーなしの201は、配達員が「荷物が配達されました！」と告げながら、どこに置いたかを教えることを拒否するようなものです。
  3. GETリクエストに対して201を返すこと：GETリクエストはリソースを作成してはなりません。それらは取得専用です。GETは200 OK（見つかった場合）または404 Not Foundを返す必要があります。
  4. 空のボディを返すこと：技術的には許可されていますが、APIコンシューマーにとってはユーザーエクスペリエンスが悪いです。これにより、即座に追加のリクエストを行うことを余儀なくされます。

Apidogで201レスポンスをテストする方法

ここで理論から実践へと移行することが不可欠になります。APIエンドポイントが常に正しい201レスポンスを返していることを確認したいはずです。Apidogは、この作業に最適なツールです。

Apidogを使えば、次のことができます。

  1. リクエストの作成：正しいJSONボディを使用して、作成エンドポイントへのPOSTリクエストを簡単に設定できます。
  2. 送信と検証：ワンクリックでリクエストを送信し、完全なレスポンスを即座に確認できます。
  3. 詳細の検査：Apidogはステータスコード（201）とすべてのヘッダーを明確に表示します（Locationヘッダーが存在し、正しいことを確認できます）。
  4. ボディの検証：レスポンスボディに、idなどのサーバー生成フィールドを含む、新しいリソースの期待される表現が含まれていることを簡単に確認できます。
  5. テストの自動化：Apidogでテストスイートを作成し、/usersへのPOSTが201ステータスとLocationヘッダーを返すことを自動的にアサートすることで、APIが後退しないことを保証できます。
ボタン

このレベルのテストは、開発者が喜んで使用するプロフェッショナルで信頼性の高いAPIを構築するために不可欠です。これにより、開発が加速され、最初からAPIへの信頼が育まれます。推測するのではなく、APIの正確な動作をリアルタイムで確認できます。

他の2xx成功コードとの比較

それぞれに明確な役割があり、それらを正しく使用することでAPIの信頼性が向上します。

高度なシナリオ：非同期作成と202 Accepted

リソースの作成が即座に行われない場合はどうでしょうか？たとえば、POST /usersリクエストがウェルカムメール、請求プロセス、および数秒かかるデータ同期をトリガーする必要がある場合、リソースがまだ完全に作成されていないため、201レスポンスは誤解を招く可能性があります。

この場合、より適切なステータスコードは202 Acceptedかもしれません。

同期的な即時作成には201を使用します。非同期的な遅延処理には202を使用します。

201 Createdを返すためのベストプラクティス

正しいステータスコードのSEOおよびUX上のメリット

ステータスコードがSEOやユーザーエクスペリエンスと関連しているとは考えないかもしれませんが、実際には関連しています。

結論：適切に設計されたAPIの証

HTTP 201 Createdステータスコードは、単なる数字以上のものです。それは明確さと優れた設計へのコミットメントです。これは、API設計者として、開発者エクスペリエンスを重視し、HTTPプロトコルの全機能を活用していることを示します。

それは単なる成功メッセージではありません。サーバーが「あなたが要求したものを構築しました。そして、ここがそれを見つける場所です。」と言っているのです。

201を適切に使用することで、より明確で信頼性が高く、使いやすいAPIを設計できます。

Locationヘッダーと新しいリソースの表現を含む201レスポンスを一貫して提供することで、APIは予測可能で自己記述的になり、統合が容易になります。これは、アマチュア的なAPIとプロフェッショナルで本番環境に対応したAPIを区別する小さな詳細です。

ですから、次にPOSTエンドポイントを構築するときは、単に200 OKで満足しないでください。具体的に。役に立つように。201 Createdを返し、クライアントにふさわしい明確な「領収書」を提供してください。そして、これを実際にテストしたいのであれば、Apidog以外に探す必要はありません。Apidogを使えば、リクエストを作成し、レスポンスを検証し、APIが正しい201 Createdレスポンスを返すことを確認できます。これにより、すべてのAPIインタラクションで常に正しく動作し、信頼と確信を築くことができます。

読むだけでなく、今すぐApidogを無料でダウンロードしてテストを始めましょう！

ボタン

ApidogでAPIデザイン中心のアプローチを取る

APIの開発と利用をよりシンプルなことにする方法を発見できる

無料会員登録ダウンロード