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