HTTP 201 Created：意味と概要

このエラーの意味と見分け方

• API クライアント、ブラウザベースのアプリケーション、監視ツール、チェッカーが 201 Created を報告します。
• レスポンスに、新しく作成されたオブジェクト、リソースメタデータ、または Location ヘッダーが含まれる場合があります。
• 特定のルート、HTTP メソッド、アカウント、リクエストペイロードでのみ発生する場合があります。
• 成功した 201 に、レスポンスボディ内のアプリケーションレベルの警告や検証情報が伴うことがあります。
• HTTP 対応エンドポイントがレスポンスを返したため、DNS と TLS のチェックが成功していても不思議ではありません。これらのチェックは HTTP ステータスとは別のものです。

可能性の高い順の主な原因

1. 想定されたリソース作成: ルートがレコード、アカウント、アップロード、ジョブ、注文、その他のリソースを意図的に作成し、成功後に 201 を返しています。
2. リソース作成用のメソッドが使用された: クライアントが、リソース作成用に設計されたエンドポイントへ POST または PUT リクエストを送信しました。201 が適切かどうかは、メソッドとルートによって決まります。
3. リクエストが繰り返された、または誤ったルートに送信された: クライアント、連携処理、フォームが、既存リソースを更新するべきときや別の URL を使うべきときに、作成用エンドポイントを対象にしている可能性があります。
4. アプリケーションまたはルーティングの動作が変更された: デプロイ、コントローラー、ハンドラー、ルートルールによって、リクエストに返されるステータスが変わった可能性があります。
5. 中間コンポーネントがレスポンスを生成または変更した: 特に直接リクエストと公開経路のリクエストでヘッダーが異なる場合、リバースプロキシ、CDN、WAF、ゲートウェイが関与している可能性があります。
6. クライアントの解釈が誤解を招いている: 監視ルールが、エラーではない HTTP レスポンスを一律に通常と異なるものとして分類している可能性があります。そのエンドポイントでは 201 が有効である場合もあります。

修正方法

まず HTTP 201 が想定されているか判断する

1. 正確な URL、HTTP メソッド、リクエストボディまたは関連パラメーター、アカウントコンテキスト、タイムスタンプを記録します。共有するメモにパスワード、Cookie、アクセストークン、その他の秘密情報を含めないでください。
2. エンドポイントのドキュメントに記載された動作またはアプリケーションの契約を確認します。作成用エンドポイントは通常 201 を返しますが、読み取り専用ページへのリクエストで通常リソースが作成されることはありません。
3. レスポンスボディとヘッダーを確認します。Location ヘッダー、リソース識別子、コンテンツタイプ、リクエスト ID、キャッシュ情報、アプリケーションレベルの警告を探します。特定のコンポーネントがレスポンスを生成した証拠としてヘッダーを扱い、ヘッダーだけで断定しないでください。
4. クライアントがリダイレクトに従ったか、途中のレスポンスを報告したかを確認します。最終レスポンスと、それ以前のレスポンスを分けて記録します。

API ユーザーまたは訪問者の場合

1. 何かを作成する操作だった場合は、リクエストを再送信する前に、アプリケーション上で新しいリソースが存在することを確認します。
2. 何も作成しない操作だった場合は、繰り返しの再試行を停止し、ルート、HTTP メソッド、クライアント設定を確認します。
3. 認証が必要な場合は、通常のアプリケーションフローでサインインし、安全かつ承認された場合にのみ再実行します。
4. サイト所有者には、サニタイズした URL とメソッド、タイムスタンプ、関連するレスポンスヘッダー、利用可能であればリクエスト ID を伝えます。認証情報、セッション Cookie、API シークレットは決して共有しないでください。

アプリケーションまたはサイトの所有者の場合

1. 安全な環境または承認済みのテストアカウントでリクエストを再現します。メソッド、URL、ステータス、レスポンスヘッダー、秘匿情報を削除したレスポンスボディを取得します。
2. レスポンスを生成したコンポーネントを特定します。アプリケーションハンドラー、Web サーバー、リバースプロキシ、CDN、WAF、その他のゲートウェイを確認します。利用可能であれば、サーバーが生成したリクエスト ID やタイミングヘッダーをログと照合します。
3. 記録したタイムスタンプに対応するアプリケーションログとインフラログを確認します。リソースが実際に作成されたか、処理が 1 回だけ実行されたか、複数回実行されたかを確認します。
4. ルート、コントローラー、リクエスト処理、認証、プロキシルール、デプロイに対する最近の変更を確認します。冪等でない作成リクエストを再試行する可能性があるクライアントには特に注意してください。
5. エンドポイントに対して 201 が誤っている場合は、レスポンスを制御する最も限定的なアプリケーションまたはルーティングルールを変更します。本番環境に適用する前に、承認を取得して変更をテストしてください。
6. 同じメソッド、URL、ペイロードで再テストし、関連する作成、読み取り、更新の各ルートもテストします。意図したステータスコードとリソース動作が維持されていることを確認してください。

予防と修正確認

• 作成や重複リクエストの動作を含め、各公開ルートで想定される HTTP メソッドとステータスコードを定義します。
• デプロイ後は、認証済み・未認証の代表的なケースで、作成、読み取り、更新の操作をテストします。
• クライアントが 201 を明示的に処理し、再試行する前に返されたリソースまたは Location ヘッダーを確認するようにします。
• 予期しないレスポンスを追跡できるよう、リクエスト識別子を使用し、アプリケーション、プロキシ、ゲートウェイのログを十分な期間保持します。
• すべての 2xx レスポンスを同じものとして扱うのではなく、ルートとメソッドごとのステータスコードの割合を監視します。
• ルーティング、認証、プロキシ、アプリケーションの変更をバージョン管理し、意図した 201 レスポンスを文書化します。

よくある質問