ステータスコード207マルチステータスとは？一括処理レポート

コンテンツ管理システムの管理パネルを構築しているとします。一度に100件の記事を削除する必要があります。100件のDELETEリクエストを個別に送信することもできますが、それは信じられないほど非効率的で、遅く、管理も困難です。この一括操作を1つのリクエストで実行し、個々のアイテムの成功または失敗に関する詳細なレポートを受け取ることができたらどうでしょうか？

これは、207 Multi-Status HTTPステータスコードが解決するために設計された、複雑で強力な問題です。

Web開発とAPIの世界では、HTTPステータスコードはクライアントとサーバーが明確に通信するのに役立つ不可欠なツールです。多くの開発者は、200 OKや404 Not Foundのような一般的なステータスコードに精通していますが、まだ遭遇したことのないような非常に特定のシナリオ向けに設計されたニッチなコードがいくつかあります。その1つが207 Multi-Statusステータスコードです。

その1つが207 Multi-Statusステータスコードです。一般的なコードとは異なり、このコードはどこにでも現れるわけではありませんが、現れるときには、特にWebDAV (Web Distributed Authoring and Versioning)や、単一の応答で複数の結果を報告する必要があるAPIにおいて、信じられないほど強力です。

この詳細なブログ記事では、207 Multi-Statusコードを基礎から探求します。その意味、仕組み、実際の使用例、そしてWebDAVのような特定のAPIコンテキストでなぜ特に役立つのかを解説します。また、207 Multi-Statusを使用するものを含むAPIを効率的にテストおよび文書化するために、Apidogを無料でダウンロードしてください。207 Multi-Statusのようなステータスコードをシミュレート、モック、テストしたい場合、カスタムサーバーを立ち上げる必要はありません。代わりに、Apidogを試してみてください。これは、APIの設計、文書化、テストができるオールインワンのAPIプラットフォームです。Apidogを使用すると、数秒でモックされた207応答を作成し、クライアントがそれをどのように処理するかを確認できます。そして、もちろん無料でダウンロードできます！

ボタン

さあ、袖をまくって、207 Multi-Statusが本当に何を意味するのか、なぜ存在するのか、そしてプロジェクトでそれを効果的に使用する方法を探っていきましょう。

207 Multi-Statusはどこから来たのか？

207ステータスコードは、Web Distributed Authoring and Versioningプロトコル、通称WebDAVから来ています。WebDAVはHTTPを拡張し、クライアントがリモートのWebコンテンツ作成操作を実行できるようにします。

特に、WebDAVはコレクション（複数のファイル/リソースを含むフォルダ）に対するバッチ操作をサポートしており、これらの操作はしばしば複雑なリソースごとの応答ステータスを持ちます。この複雑さを伝えるために、207 Multi-Statusが導入されました。

複数のファイルのコピー、移動、削除などのアクションを実行する場合、単一のHTTPステータスコードでは不十分です。一部のファイルは成功し、他のファイルは失敗する可能性があります。

そこで207 Multi-Statusが登場します。これにより、1つの応答内で各リソースの結果を詳細に報告することができます。207ステータスコードは、これらのバルク操作の結果を詳細に説明するために考案されました。

HTTP 207 Multi-Statusは実際に何を意味するのか？

207 Multi-Statusステータスコードは、HTTPのWebDAV固有の拡張機能です。これは、サーバーがリクエストの異なる部分に対して複数のステータスコードを返していることを示します。本質的に、HTTP 207 Multi-Statusステータスコードは、サーバーが単一のHTTP応答で複数のステータスコードを返す方法です。単一のリクエストに対して単一の応答ステータスを提供する一般的なHTTPコードとは異なり、207は同じ応答内で複数の独立した操作に対して個別のステータスを提供します。

これは、一度に複数のリソースに対する操作を扱う場合に特に便利で、個々のアイテムに対する応答が異なる可能性がある（一部は成功し、他は失敗する可能性がある）ためです。

207応答には通常、個々のリソースまたは操作のステータスを詳述するXMLまたはJSONボディが含まれており、多面的な応答となっています。

簡単に言えば：1つのリクエスト、多くの結果。

一般的な207応答は次のようになります。

HTTP/1.1 207 Multi-StatusContent-Type: application/xml; charset="utf-8"

<?xml version="1.0" encoding="utf-8"?>
<multistatus xmlns="DAV:">
  <response>
    <href>/files/report.pdf</href>
    <status>HTTP/1.1 200 OK</status>
  </response>
  <response>
    <href>/files/archive.zip</href>
    <status>HTTP/1.1 423 Locked</status>
  </response>
  <response>
    <href>/files/photo.jpg</href>
    <status>HTTP/1.1 404 Not Found</status>
  </response>
</multistatus>

この応答は、3つのファイルに対するバルク操作が3つの異なる結果になったことを示しています。

report.pdfは正常に処理されました（200 OK）。
archive.zipはロックされているため処理できませんでした（423 Locked – WebDAV固有のコード）。
photo.jpgは見つかりませんでした（404 Not Found）。

言い換えれば、200 OKのような単一の結果を返す代わりに、サーバーは複数の結果を1つの応答にまとめています。これは、リクエストが複数のリソースを対象とする場合や、異なる操作が異なる成功または失敗をする場合に役立ちます。

例：

バッチアップロード内の一部のファイルは成功する。
他のファイルは権限エラーのために失敗する。
複数のHTTP応答を送信する代わりに、サーバーはすべてを1つの207 Multi-Status応答にまとめる。

207応答の構造

207の力と複雑さは、常にXML形式である応答ボディにあります。

<multistatus>: すべての個々の結果をラップするルート要素。
<response>: バルク操作に関与する各個々のリソースの結果のコンテナ。
<href>: 特定のリソースへのパスを含む。
<status>: その特定のリソースの結果を記述するHTTPステータスライン（HTTP/1.1 [CODE] [PHRASE]）を含む。これが最も重要な部分です。

この構造により、信じられないほど詳細で粒度の高いレポートが可能になります。

一般的な207 Multi-Status応答は次のようになります。

HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset="utf-8"

<multistatus xmlns="DAV:">
  <response>
    <href>/file1.txt</href>
    <status>HTTP/1.1 200 OK</status>
  </response>
  <response>
    <href>/file2.txt</href>
    <status>HTTP/1.1 403 Forbidden</status>
  </response>
</multistatus>

これは次のことを意味します。

/file1.txt → 成功。
/file2.txt → アクセス拒否のため失敗。

各リソースが独自のステータスを持つことに注目してください。これが207の本質です。

207 Multi-Statusはどのように機能するのか？

クライアントが複数のリソースを含む単一のリクエスト（たとえば、バッチ削除やバッチ更新）を送信すると、サーバーは各個別の操作を個別に処理します。207応答は、これらの個別のステータスを集約し、統合されたレポートとして返します。

たとえば、クライアントが3つのファイルの削除を要求し、2つは正常に削除されたが、1つは権限のために失敗した場合、サーバーは一般的なエラーや成功を返すだけではありません。代わりに、各ファイルの詳細なステータス情報を含む207 Multi-Status応答を送信します。

応答ボディには通常、次のようなXML（または新しい実装ではJSON）が含まれます。

これにより、クライアントはどの操作が成功し、どの操作が失敗したかを明確に把握でき、よりスマートなエラー処理と応答が可能になります。

マルチステータス応答が必要な理由

207がなければ、次のようなことが起こります。

10個のファイルを削除するリクエストを送信する。
サーバーは200 OKで応答する。
しかし、3つのファイルが権限のために失敗した場合はどうなるでしょうか？あなたはそれを知ることができません。

さらに悪いことに：

サーバーは500 Internal Server Errorで応答する。
しかし実際には、2つのファイルだけが失敗し、残りは正常に削除された。

どちらの状況も曖昧で非効率的です。207を使用すると、サーバーは明確に報告できます。

ファイルA → 削除済み（200 OK）
ファイルB → 権限拒否（403 Forbidden）
ファイルC → 見つかりません（404 Not Found）

これらすべてが1つの構造化されたXMLまたはJSONボディ内に含まれます。

207が重要な理由

207 Multi-Statusステータスコードは、リソースのコレクションを管理するAPIやシステムにとって非常に重要です。その理由は次のとおりです。

詳細なフィードバック: 関与する各リソースの成功または失敗に関する詳細な情報を提供します。
より良いエラー処理: クライアントは曖昧な応答を推測したり処理したりする必要がありません。
効率的な通信: 1つのHTTPリクエストと応答で複数の操作を一度に処理できます。
バッチ操作のサポート: コンテンツ管理、クラウドストレージ、ファイル同期において基本的な一括処理を可能にします。

207がなければ、APIはマルチリソース操作のステータスを伝えるために、複数のリクエストや複雑な回避策に頼る必要がありました。

207ステータスコードの主要なユースケース

207はどこで最もよく使用されますか？

WebDAVファイル操作（複数のファイルの移動、コピー、削除、アップロード）。
バッチAPI操作（例：複数のリクエストを1つにまとめる）。
ワークフローの部分的な成功（一部のステップは成功し、他は失敗する）。
データベースまたはAPIでの一括更新。

207 Multi-Statusを使用する理由：利点

207の代替案ははるかに悪いです。

「すべてか無か」のアプローチ: 1つのアイテムでも失敗した場合、サーバーは操作全体を失敗させる可能性があります。これはユーザーエクスペリエンスが悪いものです。なぜ1つの失敗したファイルが他の99個の削除を妨げるべきでしょうか？
「サイレントな部分的な失敗」のアプローチ: サーバーは、一部のアイテムが失敗した場合でも一般的な200 OKを返すことができ、クライアントは何が機能し、何が機能しなかったかを自分で判断する必要があります。これは信頼性が低く、危険です。
「100リクエスト」のアプローチ: クライアントは100個の個別のリクエストを送信できます。これは非常に非効率的で、ネットワークオーバーヘッドでサーバーを圧倒し、アトミック性を管理するのが困難です。

207は完璧な中間点を提供します。

効率性: 1つの応答で複数の結果を返すことで、帯域幅を節約します。
アトミック性: サーバーは必要に応じてアイテムをアトミックに処理することを選択できます。
精度: クライアントは、何が成功し、何が失敗したかを正確に記述した明確で項目別のレポートを受け取ります。
堅牢性: 部分的な成功は許容され、伝達される結果です。
明確さ: 開発者はどの操作が失敗したかを正確に知ることができます。
粒度: デバッグとエラー処理に役立ちます。
一貫性: 誤解を招く単一コードの応答を回避します。

207 Multi-Statusの一般的なユースケース

WebDAVで最も顕著ですが、ユースケースはバッチ操作を実行するあらゆるAPIまたはシステムにまで及びます。

ファイルストレージAPIでのバッチ削除または更新
リソースに対する一括メタデータ更新
クライアントとサーバー間の大量のファイルの同期
アトミックなマルチリソーストランザクションを可能にするRESTful APIでのバッチ処理

バッチ操作をサポートするAPIを設計している場合、207 Multi-Statusの使用を検討することで、クライアントとサーバー間の通信を改善できます。

WebDAVを超えた実際のユースケース

WebDAVから生まれたものですが、マルチステータス応答の概念は、あらゆるバルク操作に対する最新のAPI設計において非常に有用です。

一括DELETE: 「これらの投稿をすべて削除してください。」一部は成功するかもしれませんが、権限の問題や既に削除されているために失敗するものもあります。
一括POST/作成: 「これらの10人のユーザーを作成してください。」一部のユーザー名は既に使われているかもしれません。
一括UPDATE: 「これらの製品の価格を更新してください。」一部の製品IDは無効かもしれません。
検証エンドポイント: 「これらの50件のデータレコードを検証してください。」各レコードは独自の検証エラーを持つことができます。

クライアントは207応答をどのように処理するか

クライアントが207 Multi-Status応答を受信した場合、次のことを行う必要があります。

応答ボディ（通常はXMLまたはJSON）を解析して、個々のステータスを抽出する。
各リソースの結果を個別に処理し、エラーを正確に処理する。
該当する場合、エンドユーザーに意味のあるフィードバックを提供する。
ステータスの詳細に基づいて、失敗した操作をオプションで再試行する。

この微妙な処理により、クライアントは複雑な操作全体で同期と整合性を維持できます。これは、開発者がコード内で207を明示的に処理する必要があることを意味します。

現代的なJSONの代替案

207はXMLに関連付けられていますが、それが確立するパターンは時代を超越しています。多くの最新のAPIは、XMLの代わりにJSONを使用してマルチステータス応答の概念を実装しており、多くの場合、200 OKステータスコードを使用します。

以前の例の現代化されたバージョンは次のようになるかもしれません。

HTTP/1.1 200 OKContent-Type: application/json
{
  "results": [
    {
      "href": "/files/report.pdf",
      "status": 200,
      "message": "OK"
    },
    {
      "href": "/files/archive.zip",
      "status": 423,
      "message": "Locked"
    },
    {
      "href": "/files/photo.jpg",
      "status": 404,
      "message": "Not Found"
    }
  ]
}

このアプローチは、JSON中心の世界で作業する開発者にとって、より受け入れやすいことが多いです。ただし、HTTP標準に厳密に従う場合は、公式の207ステータスコードを使用する方が意味的に正しいです。

APIは207応答をどのように使用するか

最新のAPIは、バッチ操作で207 Multi-Statusを採用できます。

REST API: ユーザーの一括更新を処理する際にマルチステータスの結果を返します。
GraphQL API: 複数のフィールド応答をバンドルし、それぞれに成功/失敗情報を含めます。
ファイルストレージAPI: ファイルごとのアップロード結果を報告します。

207を使用することで、APIはより透過的になり、混乱を避けることができます。

Apidogで207応答をテストする

207を返すAPIのテストは、単純なエンドポイントのテストよりも複雑です。XMLの構造と、各個別のアイテムのステータスコードを検証する必要があります。207 Multi-Status応答の処理は、その複雑なペイロードのために難しい場合があります。Apidogはこのタスクに理想的なツールです。

Apidogを使用すると、次のことができます。

バルクリクエストの作成: サーバーでバルク操作をトリガーするリクエストを簡単に設定できます。
XML応答の解析: ApidogはXML応答を構造化された読みやすい形式で表示できるため、各<response>ブロックをすばやく確認できます。
高度なアサーションの記述: Apidogで次のテストスクリプトを記述できます。

全体のステータスコードが207であることをアサートする。
<multistatus>応答内の各アイテムをループ処理する。
特定のりソースが期待される個別のステータスコードを持っていることを確認する（例：「/files/photo.jpgが404ステータスを持っていることをアサートする」）。

4. エラーの処理: 207応答に含まれる成功と失敗の入り混じった状態を、クライアントアプリケーションロジックがどのように処理すべきかをテストします。

ボタン

このレベルのテストは、部分的な成功にインテリジェントに反応できる信頼性の高いクライアントを構築するために不可欠です。今すぐApidogを無料でダウンロードして、マルチステータスやその他のHTTPコードでの体験を簡素化してください。SwaggerやPostmanとは異なり、Apidogはテストを超えて、現実世界のワークフローを設計し、文書化することを目的としています。

207でよくある間違い

曖昧なエラーを返す → 207の目的を損なう。
形式を混在させる → XML（WebDAV）またはJSON（最新のAPI）に固執する。
使用法を文書化しない → クライアントは応答を解析する方法を知らない。

207 Multi-Statusの実装：ベストプラクティス

207を使用するAPIを構築している開発者であれば、以下の点を念頭に置いてください。

応答のフォーマットについてはWebDAVの仕様に従う（該当する場合）。
各リソース応答には明確で一貫したステータスコードを使用する。
応答ボディが解析しやすいように、整形式のXMLまたはJSONであることを確認する。
バッチ操作エンドポイントと207応答の構造を明確に文書化する。
Apidogのようなツールを使用して、バッチエンドポイントをテストし、207応答を詳細に検査する。

課題と考慮事項

クライアントの複雑さ: クライアントは「207対応」である必要があります。メインのステータスコードを確認するだけで済むわけではなく、応答ボディを解析し、各結果を個別に処理する必要があります。これにより、クライアント側のコードの複雑さが増します。
アトミック性: 1つのアイテムが失敗した場合、操作全体を失敗させるべきか、それとも部分的に成功させるべきか？サーバーの設計でこれを決定する必要があります。207応答は、部分的な「最善の努力」アプローチを意味します。
パフォーマンス: 1つのリクエストで多数のアイテムを処理することは、サーバーに負担をかける可能性があります。タイムアウトと制限を実装することが重要です。

これらの課題にもかかわらず、バッチ処理が必要な場合には、207を採用する価値は十分にあります。

結論：207 Multi-Statusステータスコードがあなたのツールボックスにあるべき理由

HTTP 207 Multi-Statusコードは、マルチリソース操作、バッチ処理、および複雑なAPIを扱う際に不可欠なツールです。これは、より単純なステータスコードではうまく処理できない、単一の応答で個々の結果に関する詳細で構造化されたフィードバックをサーバーが提供できるようにします。そのXMLベースのWebDAVのルーツは時代遅れに感じるかもしれませんが、基盤となるパターンは、データのコレクションを効率的に管理する必要がある複雑なWebアプリケーションの世界でこれまで以上に重要です。207 Multi-Statusコードは日常のブラウジングではあまり見かけないかもしれませんが、WebDAV、バッチ操作、または複数の結果を返すAPIを扱う開発者にとっては、状況を一変させるものです。

これは、サーバーが単一の応答内で複数の結果を明確かつ効率的に伝達することを可能にします。これは、単純な200 OKや500 Internal Server Errorでは処理できません。ほとんどの一般的なAPIのニーズでは、より単純なステータスコードを使用するでしょう。しかし、バルク操作という特定のニッチな分野では、207を理解することで、それを正しく行うための青写真が得られます。これにより、クライアントに詳細なフィードバックを提供することの重要性が教えられ、部分的な成功の複雑さを処理できる堅牢でユーザーフレンドリーなアプリケーションを構築できるようになります。

マルチステータスの動作が必要なAPIを設計またはテストしている場合、アドホックなモックサーバーに苦労する必要はありません。207ステータスコードはあなたの味方です。そして、このレベルの洗練されたAPIを構築または統合する準備ができたら、Apidogのようなツールは、これらの複雑なインタラクションをデバッグ、テスト、検証するために必要な機能を提供し、アプリケーションがマルチステータス応答内のすべてのステータスを正しく処理することを保証します。これは、207 Multi-Statusのような複雑なHTTPステータスコードを利用するAPIをテストするための完璧なツールであり、より優れたAPIをより速く構築するのに役立ちます。207 Multi-Status応答を簡単に設計、モック、テストできるだけでなく、チームのためにクリーンなAPIドキュメントも生成できます。

APIがますます複雑で相互接続された世界において、207 Multi-Statusのようなコードを理解し活用することで、時間を節約し、エラーを減らし、開発者エクスペリエンスを向上させることができます。

ボタン