2

削除されたオブジェクトをリクエスター（APIのクライアント）にディスパッチするための一般的なデザインパターンはありますか？

私たちが抱えている課題：

  1. APIでオブジェクトが完全に削除されると、クライアントはオブジェクトがなくなったことを認識せず、ローカルに保持します（APIは特定の日付以降に変更されたオブジェクトのみを表示するため）
  2. オブジェクトのプロパティで削除されたことを表示できるようにすると（「deleted = TRUE」など）、最終的にAPI内のオブジェクトの数が増え、転送速度が低下します。

私たちが検討しているもう1つのオプションは、APIに個別のエンドポイントを設定して、削除されたオブジェクトのリストのみを表示することです（これは誰もが使用するパターンですか？）。

ローカルオブジェクトを削除するための最も「RESTfulな方法」を探しています。

4

3 に答える 3

2

私がそれを処理する方法は、あなたの #1 のバリエーションです。各アイテムlast updatedにはデータベースにフィールドがあり、何かが削除された場合、削除されたアイテムの別のテーブルにエントリを作成し、更新された値は削除されたときです。

クライアントは、ローカルに保存された独自のlast updated値である「X 以降の変更」を要求するリクエストを行います...新しいデータと削除されたアイテムの配列を返します。次に、クライアントでそれらの値を消去します

于 2012-07-22T23:37:04.493 に答える
1

古いデータは常にクライアント/サーバー アプリケーションの問題です。クライアントがデータをロードし、サーバー上でオブジェクトが削除された後、クライアントが DELETE リクエストを送信した場合、RESTFul で行うべきことは、「見つからない」ことを示す 404 を返すことです。クライアントが DELETE を送信して 404 を取得した場合、リソースが下から削除されていたことをクライアントが認識している場合...

于 2012-07-22T23:35:40.613 に答える
0

リソースをリストではなくチェンジセットと考えたらどうでしょうか?

例えば。git または SVN にあるものを変更します。

このように、常に「ヘッド」バージョンがあり、クライアントには常に何らかのバージョンがあり、リソースはクライアントの最後とヘッドの間の変更です。

そうすれば、バージョン管理システムを調べたり使用したりすることで、学んだことをすべて適用できます。

より複雑なものが必要な場合、背後にある科学は運用変換 (OT) と呼ばれます - http://en.wikipedia.org/wiki/Operational_transformation

于 2012-07-22T23:43:48.023 に答える