次のような構造の REST サーバーにいくつかのリソースがあります。
/someResources/foo/someResources/bar/someResources/bazここで、someResourceは遠く離れた分散オブジェクトのサーバー表現です。
その「分散オブジェクト」の表現をネットワークで調べてサーバーのキャッシュを更新することにより、サーバーにその表現を「リフレッシュ」するように伝えたいのです。つまり、単純に新しい値を PUT することはできません。
これに対するクリーンなRESTの方法は何ですか?
a)/refreshes/新しい「更新リクエスト」に POST しますか?
b) PUT (白紙の文書)http://ip/someResourcesですか?
c) 他に何か?
(a) は、更新コマンドを識別して追跡するための ID を提供するので気に入っていますが、作成するリソースが多すぎるのではないかと心配しています。何かアドバイス？
「リフレッシュ」リソースアプローチを使用します。これには2つの大きなメリットがあります
(a) ライフサイクル操作 (コピー、クローン、移動) と同様に、更新の目的は基盤となるリソースの機能とは直交するため、完全に分離する必要があります。
(b) リフレッシュの進行状況を確認する方法を提供します。リフレッシュ リソースの外部状態は、'status' または 'progress' 属性を提供します。
このようにライフサイクル操作を実装しましたが、関心の分離は大きな設計上の利点です。
これを管理するもう 1 つの方法は、サーバーがリソースの表現を一定期間キャッシュできるようにし、タイムアウト後に実際の状態のみを実際にチェックすることです。このモデルでは、サーバーは実際には中間キャッシング リソースであり、HTTP キャッシングの動作に従う必要があります。詳細については、こちらを参照してください。以下に、キャッシュされた値をオーバーライドするクライアントについて説明する非常に関連性の高いセクションを引用します。
13.1.6 クライアント制御
の振る舞い オリジンサーバー (および、より少ない程度ではあるが、応答の経過時間に寄与する中間キャッシュ) が有効期限情報の主要な情報源ですが、場合によっては、クライアントがキャッシュの制御を必要とする場合があります。検証せずにキャッシュされた応答を返すかどうかの決定。クライアントは、Cache-Control ヘッダーのいくつかのディレクティブを使用してこれを行います。
クライアントの要求は、検証されていない応答を受け入れても構わないと思っている最大年齢を指定することができます。ゼロの値を指定すると、キャッシュはすべての応答を強制的に再検証します。クライアントは、応答が期限切れになるまでの最小残り時間を指定することもできます。これらのオプションはどちらも、キャッシュの動作に対する制約を増やすため、キャッシュのセマンティック透過性の近似をさらに緩和することはできません。
また、クライアントは、失効の最大量まで、失効した応答を受け入れるように指定することもできます (MAY)。これにより、キャッシュの制約が緩和されるため、セマンティック透過性に関するオリジン サーバーの指定された制約に違反する可能性がありますが、切断された操作、または接続が不十分な場合の高可用性をサポートするために必要になる場合があります。
クリス
HTTP キャッシングはこれを可能にしているようです。 http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.1.6
ヘッダー max-age=0 を設定すると、クライアントが新しいバージョンを必要としていることがサーバーに通知されます。このようにして、引き続き GET を使用できます。