表現が遅延して作成される一連のリソースがあります。これらの表現を構築するための計算には、サーバーの負荷、特定のリソース、および月の満ち欠けに応じて、数ミリ秒から数時間かかることがあります。
リソースに対して受信した最初の GET 要求によって、サーバーで計算が開始されます。計算が数秒以内に完了すると、計算された表現が返されます。それ以外の場合は、202 "Accepted" ステータス コードが返され、クライアントは最終的な表現が利用可能になるまでリソースをポーリングする必要があります。
この動作の理由は次のとおりです。結果が数秒以内に得られる場合は、できるだけ早く取得する必要があります。それ以外の場合、いつ利用可能になるかは重要ではありません。
メモリが限られていることとリクエストの量が非常に多いため、NIO もロング ポーリングもオプションではありません (つまり、ほぼ十分な数の接続を開いたままにしておくことはできず、すべてのリクエストをメモリに格納することさえできません。一度「数秒」)超過した要求を保持します)。同様に、クライアントの制限により、代わりに完了コールバックを処理できません。最後に、POST 先の「ファクトリー」リソースを作成することに興味がないことに注意してください。余分なラウンドトリップは、必要以上に区分的リアルタイム制約に失敗することを意味するためです (さらに、これは余分な複雑さです。また、これはキャッシュの恩恵を受けます）。
GET リクエストに応答して 202 の "Accepted" ステータス コードを返すことについては、いくつかの論争があると思います。実際に見たことがないので、その最も直感的な使用法は安全でないメソッドへの応答ですが、私は決して特にそれを思いとどまらせる何かを見つけました。さらに、安全性と冪等性の両方を維持していませんか?
では、人々はこのアプローチについてどう思いますか?
編集:これはいわゆるビジネス Web API 用であり、ブラウザー用ではありません。