REST API 設計:サーバーにリソースのセットを「更新」するよう指示します。

Question

REST サーバー上には次のような構造のリソースがいくつかあります。

• /someResources/foo
• /someResources/bar
• /someResources/baz

どこ someResource は、遠く離れた分散オブジェクトのサーバー表現です。

ネットワーク内で「分散オブジェクト」を調べてサーバーのキャッシュを更新することで、その「分散オブジェクト」の表現を「更新」するようにサーバーに指示したいと考えています。新しい値を単純に PUT することはできません。

これを実現するクリーンな REST 方法は何ですか?

a) に POST するのか /refreshes/ 新しい「更新リクエスト」?

b) PUT (白紙の文書を使用) を行うのですか? http://ip/someResources ?

c) 他に何かありますか?

(a) は更新コマンドを識別して追跡するための ID を提供するので気に入っていますが、作成するリソースが多すぎるのではないかと心配しています。何かアドバイス？

Answer 1

私は「リフレッシュ」リソースアプローチを採用します。これには 2 つの大きな利点があります

(a) ライフサイクル操作 (コピー、クローン、移動) と同様に、リフレッシュの目的は基礎となるリソースの機能と直交しているため、完全に分離する必要があります。

(b) リフレッシュの進行状況を確認する何らかの方法が提供されます。リフレッシュ リソースの外部状態により、「ステータス」または「進行状況」属性が提供されます。

この方法でライフサイクル操作を実装しましたが、懸念事項の分離は設計上の大きな利点です。

より良いアプローチ

これを管理するもう 1 つの方法は、サーバーがリソースの表現を一定期間キャッシュし、タイムアウト後にのみ実際の状態を実際にチェックできるようにすることです。このモデルでは、サーバーは実際には中間キャッシュ リソースであり、HTTP キャッシュ動作に従う必要があります。を参照してください。 ここ 詳細については。以下に、クライアントによるキャッシュされた値のオーバーライドについて説明している、非常に関連性の高いセクションを引用します。

13.1.6 クライアント制御の動作オリジン サーバー (および程度は低いですが、応答の経過時間に影響する中間キャッシュ) が有効期限情報の主なソースですが、場合によっては、キャッシュされたデータを返すかどうかについてクライアントがキャッシュの決定を制御する必要がある場合があります。検証せずに応答します。クライアントは、Cache-Control ヘッダーのいくつかのディレクティブを使用してこれを行います。

クライアントのリクエストは、未検証のレスポンスを受け入れる最大期間を指定してもよい(MAY)。値 0 を指定すると、キャッシュはすべての応答を強制的に再検証します。 クライアントは、応答が期限切れになるまでの最小残り時間を指定してもよい(MAY)。これらのオプションは両方とも、キャッシュの動作に対する制約を増やすため、キャッシュのセマンティック透明性の近似をこれ以上緩和することはできません。

クライアントは、一定の最大量までの古い応答を受け入れることを指定してもよい(MAY)。これにより、キャッシュの制約が緩和されるため、セマンティック透過性に関してオリジン サーバーが指定した制約に違反する可能性がありますが、切断された操作や、接続が不十分な場合の高可用性をサポートするために必要な場合があります。

クリス

Answer 2

HTTP キャッシュによりこれが可能になるようです。 http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.1.6

ヘッダー max-age=0 を設定すると、クライアントが新しいバージョンを必要とすることがサーバーに指示されます。こうすることで、GET の使用を続けることができます。