「まだ処理中」のHTTPステータスコード

最終的な処理のために長時間実行されるタスクをキューに入れることをサポートするRESTful APIを構築しています。

このAPIの一般的なワークフローは次のとおりです。

1. ユーザーがフォームに入力する
2. クライアントがデータをAPIに投稿します
3. APIは202 Acceptedを返します
4. クライアントはユーザーをそのリクエストの一意のURLにリダイレクトします（/results/{request_id}）
5. 〜最終的に〜
6. クライアントは再度URLにアクセスし、そのページで結果を確認します。

問題はステップ6にあります。ユーザーがページにアクセスするたびに、API（GET /api/results/{request_id}）にリクエストを提出します。理想的には、タスクは今までに完了しており、タスクの結果と共に200 OKを返します。

しかし、ユーザーは強引であり、結果がまだ処理を完了していないときに、多くの熱心な更新が期待されます。

次のことを示すステータスコードの最良の選択肢は何ですか？

• このリクエストが存在する、
• まだ終わっていない、
• しかし、それも失敗していません。

単一のコードがすべてを通信することを期待していませんが、クライアントにコンテンツを期待させるのではなく、メタデータを渡すことができるものが欲しいのです。

202を返すことは理にかなっています。なぜなら、それはここでは他の意味を持たないからです。それはGET要求であるため、おそらく「受け入れられる」ものは何もありません。それは合理的な選択でしょうか？

これらすべてに対する明白な代替手段-機能するが、ステータスコードの1つの目的を無効にする-は、常にメタデータを含めることです。

200 OK

{
    status: "complete",
    data: {
        foo: "123"
    }
}

...または...

200 OK

{
    status: "pending"
}

次に、クライアント側で、リクエストが完了したかどうかを判断するためswitchに（ため息をつきます）response.data.status。

これは私がやるべきことですか？または、より良い代替手段はありますか？これは私にとってWeb 1.0だと感じています。

HTTP 202が受け入れられました（HTTP / 1.1）

HTTP 202 Acceptedステータスを探しています。RFC 2616を参照してください：

要求は処理のために受け入れられましたが、処理は完了していません。

HTTP 102処理（WebDAV）

RFC 2518では、次の使用を推奨していHTTP 102 Processingます。

102（処理中）ステータスコードは、サーバーが完全な要求を受け入れたがまだ完了していないことをクライアントに通知するために使用される暫定応答です。

ただし、警告があります。

サーバーは、要求が完了した後に最終応答を送信する必要があります。

最後の文をどう解釈するかわかりません。サーバーは処理中に何も送信せず、完了後にのみ応答する必要がありますか？または、処理が終了したときにのみ応答を強制的に終了しますか？これは、進行状況を報告する場合に役立ちます。HTTP 102を送信し、バイトごとに（または行ごとに）応答をフラッシュします。

たとえば、長くても線形のプロセスの場合、100文字のドットを送信して、各文字の後にフラッシュできます。クライアント側（JavaScriptアプリケーションなど）が正確に100文字を想定していることを知っている場合、ユーザーに表示する進行状況バーと一致させることができます。

別の例は、いくつかの非線形ステップで構成されるプロセスに関するものです。各ステップの後、最終的にユーザーに表示されるログメッセージをフラッシュして、エンドユーザーがプロセスの進行状況を把握できるようにすることができます。

プログレッシブフラッシュの問題

この手法にはメリットがありますが、お勧めしません。その理由の1つは、接続を強制的に開いたままにすることです。これは、サービスの可用性の点で損害を与える可能性があり、適切に拡張できません。

より良いアプローチは、応答してHTTP 202 Accepted、ユーザーが後であなたに戻って処理が終了したかどうかを判断させることです（たとえば、プロセスまで/process/resultHTTP 404 Not FoundまたはHTTP 409 Conflictで応答するような特定のURIを繰り返し呼び出すことによって）終了し、結果の準備ができました）、またはメッセージキューサービス（例）またはWebSocketsを介して、たとえばクライアントをコールバックできる場合、処理が完了したときにユーザーに通知します。

実用例

ビデオを変換するWebサービスを想像してください。エントリポイントは次のとおりです。

POST /video/convert

HTTPリクエストからビデオファイルを取得し、それを使用して魔法をかけます。魔法はCPUに負荷がかかるため、リクエストの転送中にリアルタイムで実行できないと想像してください。これは、ファイルが転送されると、サーバーがHTTP 202 AcceptedJSONコンテンツで応答することを意味します。将来のどこかで準備が整い、ID 123で利用できるようになります。」

クライアントは、処理の終了時に通知されるメッセージキューにサブスクライブする可能性があります。終了すると、クライアントは次の場所に移動して処理済みのビデオをダウンロードできます。

GET /video/download/123

につながるHTTP 200。

クライアントが通知を受信する前にこのURIを照会するとどうなりますか？HTTP 404実際、ビデオはまだ存在しないため、サーバーは応答します。現在準備中です。リクエストされることはありません。過去のある時点で存在し、後で削除される場合があります。重要なのは、結果のビデオが利用できないことです。

さて、クライアントが最終的なビデオだけでなく、進行状況（メッセージキューサービスや同様のメカニズムがない場合はさらに重要になる）も気にする場合はどうでしょうか？

この場合、別のエンドポイントを使用できます。

GET /video/status/123

これは、次のような応答を返します。

HTTP 200
{
    "id": 123,
    "status": "queued",
    "priority": 2,
    "progress-percent": 0,
    "submitted-utc-time": "2016-04-19T13:59:22"
}

リクエストを繰り返し行うと、次のようになるまで進行状況が表示されます。

HTTP 200
{
    "id": 123,
    "status": "done",
    "progress-percent": 100,
    "submitted-utc-time": "2016-04-19T13:59:22"
}

これらの3種類の要求を区別することが重要です。

• POST /video/convertタスクをキューに入れます。一度だけ呼び出す必要があります。もう一度呼び出すと、追加のタスクがキューに入れられます。
• GET /video/download/123操作の結果に関するものです。リソースはビデオです。ここでは、処理（要求の前に、要求とは独立して実際の結果を準備するために内部で行われた処理）は無関係です。1回または数回呼び出すことができます。
• GET /video/status/123処理自体に関係します。何もキューに入れません。結果のビデオは気にしません。リソースは、処理自体です。1回または数回呼び出すことができます。

これらすべてに対する明白な代替手段-機能するが、ステータスコードの1つの目的を無効にする-は、常にメタデータを含めることです。

これが正しい方法です。ドメイン固有のログ（別名、ビジネスロジック）に関するリソースの状態は、リソースの表現のコンテンツタイプの問題です。

ここでは、実際には異なる2つの異なる概念が混同されています。1つは、リソースのクライアントとサーバー間の状態転送のステータスです。もう1つは、ビジネスドメインがそのリソースのさまざまな状態を把握するコンテキストにおけるリソース自体の状態です。後者はHTTPステータスコードとは関係ありません。

HTTPステータスコードは、そのリソースの詳細に関係なく、処理対象のリソースのクライアントとサーバー間の状態転送に対応していることに注意してください。GETリソースが現在の状態にあるリソースの表現をサーバーに要求しているとき、それは鳥の絵かもしれませんし、Word文書かもしれませんし、現在の外部tempかもしれません。HTTPプロトコルは気にしません。HTTPステータスコードは、そのリクエストの結果に対応しています。DID POSTクライアントからサーバはその後、それをクライアントが表示できるURLを与えたサーバーに、サーバー移転リソースに？はい？それが201 Created応答です。

リソースは、現在「レビュー対象」状態にある航空会社の予約である可能性があります。または、「承認済み」状態の製品発注書である場合があります。これらの状態はドメイン固有のものであり、HTTPプロトコルの目的ではありません。HTTPプロトコルは、クライアントとサーバー間のリソースの転送を処理します。

RESTとHTTPのポイントは、プロトコルがリソースの詳細に関与しないことです。これは意図的なものであり、ドメイン固有の問題には関係ないため、ドメイン固有の問題について何も知らなくても使用できます。HTTPステータスコードがそれぞれの異なるコンテキスト（航空会社の予約システム、画像処理システム、ビデオセキュリティシステムなど）で意味するものを再解釈しません。

ドメイン固有のものは、クライアントとサーバーContent Typeがリソースに基づいて相互に判断するためのものです。HTTPプロトコルはこれにとらわれません。

クライアントがリクエストリソースの状態が変化したことをどのように判断するかについては、ポーリングはクライアントで制御を維持し、切断されていない接続を想定しないため、最善の方法です。特に、状態が変化するまで数時間かかる可能性がある場合。RESTで地獄だと言ったとしても、接続を開いたままにしておきます。何時間も接続を開いたままにして、何もうまくいかないと仮定するのは悪い考えです。ユーザーがクライアントを閉じた場合、またはネットワークが外に出た場合はどうなりますか。粒度が時間の場合、クライアントは、リクエストが「保留」から「完了」に変わるまで、数分ごとに状態をリクエストできます。

物事を明確にするのに役立つことを願っています

このブログからの提案は合理的だと思いました：RESTと長時間実行ジョブ。

要約する：

1. サーバーは、クライアントがステータスを確認するためのURIに「Location」ヘッダーを設定したコード「202 Accepted」を返します（例：「/ queue / 12345」）。
2. 処理が終了するまで、サーバーはステータスクエリに「200 OK」とジョブステータスを示すいくつかの応答データで応答します。
3. 処理が完了すると、サーバーはステータスクエリに「303 See Other」と「Location」で最終結果へのURIを含めて応答します。

まだ利用できないリソースのHTTPステータスコードは、リソースが生成中のため存在しない場合、404応答ではなく409競合応答を返すことを提案しています。

w3仕様から：

10.4.10 409競合

リソースの現在の状態と競合するため、要求を完了できませんでした。このコードは、ユーザーが競合を解決してリクエストを再送信できることが予想される場合にのみ許可されます。応答本文には十分な情報を含める必要があります

ユーザーが競合の原因を認識するための情報。理想的には、応答エンティティには、ユーザーまたはユーザーエージェントが問題を修正するのに十分な情報が含まれているはずです。ただし、それは不可能な場合があり、必須ではありません。

競合は、PUT要求への応答で発生する可能性が最も高くなります。たとえば、バージョン管理が使用されており、PUTされているエンティティに以前の（サードパーティの）リクエストによって行われたものと競合するリソースへの変更が含まれている場合、サーバーは409レスポンスを使用してリクエストを完了できないことを示すことがあります。この場合、応答エンティティには、応答のContent-Typeで定義された形式の2つのバージョンの違いのリストが含まれる可能性があります。

409コードは「ユーザーが競合を解決してリクエストを再送信できる可能性があると予想される状況でのみ許可されている」ため、これはやや厄介です。応答本文には、「このリソースは現在生成中です。[TIME]に開始され、[TIME]に完了すると推定されます。」などのメッセージ（おそらく、APIの残りの部分と一致する応答形式）を含めることをお勧めしますあとでもう一度試してみてください。"

リソースを要求しているユーザーがそのリソースの生成を開始したユーザーでもある可能性が高い場合にのみ、409アプローチを提案することに注意してください。リソースの生成に関与していないユーザーは、404エラーがわかりにくくなります。