1

サーバー上のアイテムのキューを考えてみましょう。次にクライアントは、REST Web サービスを使用して、一度に 10 個のキューに入れられたアイテムを読み取ります。当然、クライアントがこれらのアイテムを消費すると、サーバーはそれらをサーバー側で削除する必要があります。

Q: 堅牢性、ネットワーク負荷、および安らぎの両方を考慮する場合、どのアプローチが最適ですか?

考えられる解決策は次の 3 つです。

クライアントは新しいアイテムを要求します。サーバーはその後...

  1. アイテム 1..10 ( GET) を送信し、すぐに削除します。うまくいけば、アイテムはクライアントに到着しました。
  2. アイテム 1..10 を送信し ( GET)、クライアントは 1..10 の ACK を送信し ( DELETE)、サーバーはアイテムを削除します。
  3. アイテム 1..10 ( GET) を送信します。次にクライアントが 11..20 ( GET) を要求すると、以前の項目はサーバーから削除されます。

＃1と＃3の両方が安らかな原則に違反していると思います。例:DELETEメソッドのみがオブジェクトを削除できます。ただし、どちらも ACK コマンドのデータ トラフィックを回避します。

ここで何が最善かわかりません。おそらく、さらに良い解決策がありますか？

4

1 に答える 1

0

投票形式での回答は次のとおりです。選択肢をもう少し明確にするのに役立つことを願っています。

REST スタイルのアーキテクチャでは、APIの実装によって基になるプロトコルの実装が変更されないことが重要です。この場合、GET要求がべき等であることを意味します。冪等性とは、基礎となるリソースが変更できない、または永遠に消えない (AKA 削除される) ことを意味するわけではありませんが、それが a の直接的または間接的な結果として発生することGETは、プロトコルの精神に従っていないようです。

メッセージの配信を保証するシステムでは、意図した受信者がメッセージを正常に受信したことを確認するために、ある種のハンドシェイクが必要です。HTTP が問題のプロトコルである場合、それは 2 つの要求を意味します。の動作がGETリソースを遅延削除するように変更された場合でも、ハンドシェイクはまだ存在します。時間内にシフトされただけです。繰り返しになりますが、HTTP が問題のプロトコルである場合、そのハンドシェイクの取得と削除には既存のGETandのメソッドを使用するのが最善のようです。DELETE結果は、同等のアプローチよりもネットワークに負担をかけるべきではありません。

于 2011-12-24T01:00:13.353 に答える