Tim Bray氏は新しい投稿遅いRESTのなかでこの問題に答えようとしている：
RESTfulなやり取りで、状態を変更する操作（POST、PUT、DELETE）が予測できないような多大な遅延時間を伴うとき、どう扱ったらいいのでしょう？
氏は３つの異なる方法を説明している。これらの方法はKenaiプロジェクトの「非同期処理要求の扱い方」という提案に対して、提示されたものだ。以下の方法が含まれている:
- リソースを基にした方法。この方法は
新しく"状態"を表すリソースを使います。このリソースは以下のフィールドを保持します。:
このリソースは以下のように使うことができる:- "uri" - クライアントが処理完了を問い合わせるためにGETすることができるURI。受信された各非同期処理は状態を表すユニークなURIを与えられています。このため、複数の処理を起動し、一度に追跡できます。
- "status" - 数値型のコード。処理の完了ステータス（0=success、0以外の数値=errorコード）状態を表します。この値が返されるのは、 "progress"フィールドの値が100を返す時だけです。
- "message" - 完了状態を報告するためのメッセージ。人間が読めるようになっています。これも返されるのは、"progress"フィールドが100を返す時だけです。
- "progress" - 処理の進捗具合を表すパーセントの値。処理が完了したとき(処理の成功、失敗に関わらず)にだけ100を返さなければなりません。
すべてのPUT/POST/DELETEに対して、 "202 処理中"と処理の"状態"を表すリソースを返します。 そして... 開発者が簡単にポーリングできるようにフックを提供します。
- コメット型の実装－長いリクエストの実行を扱うためにHTTPチャンネルをオープンにしておく。
- 最初のレスポンスは、HTTPステータス202("受理")を含まなければなりません。... そして、エンティティボディにはこの処理の最初の状態をあらわすリソースが含まれている必要があります。この状態を表すリソースには、"uri"フィールドと"progress" フィールドに必ず値が設定されていなければなりません。そして"progress"フィールドには処理が始まっていることを示す0値が設定されています。
- 最初のレスポンスに含まれているURIはGETリスエストに対して、処理の最新の状態をあらわすリソースを返さなければなりません。通常、"progress"フィールドの値は100まで増えていきますが、処理が完了するまでは100が設定されてはなりません。
- 処理が完了したとき(処理の成功、失敗に関わらず)、 処理の"最終的な"状態をあらわすリソースが返される必要があります。"progress"フィールドには100が設定され、"status"フィールドには(処理成功をあらわす)0が設定されるか、または、処理が成功しなかった場合は0以外の値が設定されます。
- "ウェブ・フック" - ２つの独立した"一方向の"通信を使う。ひとつが長時間かかるリクエストを実行し、もうひとつがそのリクエストの処理完了をリクエスト実行者に通知する。
- 処理リクエストは"webhook"フィールドを含むことができます。このフィールドにはクライアントがコールバックしてほしいURIが設定されています。このフィールドが存在しなければ、コールバックは実行されません。
- 処理が完了したとき(処理の成功、失敗に関わらず)、サーバは"webhook" フィールドに設定されたURIにPOSTを実行します。... このPOSTのエンティティボディは処理の最終的な状態をあらわすリソースが含まれます。
- クライアントは、このPOSTのエンティティボディの"uri"フィールドの値と、最初のレスポンスの処理状態をあらわすリソースに含まれる"uri"フィールドの値を比べ、元のリクエストの完了通知を見つけます。または、各非同期リクエストごとにユニークなウェブ・フック用のURIを提供することで元のリクエストを見つけることができます。
Tim氏はこの投稿の最後でこの方法をどう思うか問いかけている:
... "遅いREST"で扱った話が、将来これらの方法を標準化するときに、再び現れるのは十分にあり得ることです。
Tim氏の投稿は相当な数の反応を引き起こした。中には、William Vambenepe氏の反応のように興味深いものがある。氏はTIm氏の投稿の中で提示された問題と解決策をWS*標準が明確にした問題と解決策、中でもWSRFとWS-Notificationsの問題と解決策とを比較している。William氏によると:
WSRFはこの利用方法（遅い生成処理）を完全にカバーしていません。しかし、WS-ResourceLifetimeとWS-Notificationの間で、多少類似した利用方法に取り組んでいるのがわかります（あなたも次にこの取り組みに出くわすかもしれません）。この方法にWS-MakeConnection（WS-RXの一部）を追加すれば、 "ウェブ・フック"の考え方はとても実践的になるでしょう。...私はいつも"REST"と"WS-(死の)星マーク"は互いに近づきつつあると感じていました。
多くの違い(現実的な、あるいは教条的な)があるにも関わらず、RESTとWS*の双方の陣営は、現実的な問題を解決しようとして、結果的に同じような困難に直面している。互いの経験と実装から学ぶことが、双方のためになるのは明らかだ。