キャッシュを無効にするための適切なAPIの設計方法を教えてください。

Question

私はService2からのデータを必要とするアプリケーションを持っています。これは、バッキングデータベースが更新されない限り、特定のリクエストに対して同じ回答を永遠に返します。データベースはまれにしか更新されません。年に2回は言いましょう。

アプリケーションがService2からの回答をキャッシュするが、アプリケーションのキャッシュを無効にするために外部的に機能を提供するようにソリューションを設計したいと考えています。アプリケーションからRESTfulなWebサービスを公開することを考えましたが、正しく設計する方法は混乱しています。

/application/cache/invalidateは、RESTfulでないURLです。私は/application/cache/をHTTP POSTで呼び出すと考えていました。しかし、適切なRESTfulデザインでは、POSTを使用してリソースを更新する場合、更新するコンテンツをリクエストの本文に含める必要があります。

"InvalidateCache"安らかなWebサービスを設計する正しい方法は何ですか？

Answer 1

はDELETE代わりのPOSTの使用を検討してURLのために：RESTで

/application/cache/ 

、PUTとDELETE両方がindempotentアクションであると考えられています。つまり、同じ結果のリソース状態で複数回繰り返すことができます。この場合、あなたのキャッシュはリソースであり、複数のDELETEの結果は同じ状態であり、クリアされたキャッシュになります。

キャッシュの内容を消去し、キャッシュオブジェクト自体を削除しないことを明確にするために、URLにディスクリプタを追加することを検討できます。何かのように

/application/cache/contents 

おそらく、それはあなた次第です。そのルートを使用すると、必要に応じてキャッシュから選択的に削除することもできます。

Answer 2

これはあなたの質問に直接答えないかもしれませんが、HTTP ETagsを調べて、RESTfulデザインでのキャッシュに最適です。

アプリケーションは、Service2からリソースを取得し、リソースをETagヘッダーとともに返します（最後に変更されたタイムスタンプまたはハッシュになる可能性があります）。アプリケーションは、そのリソースをETagとともにキャッシュします。

アプリケーションは、リソースで再度作業する必要がある場合、キャッシュにあるETagヘッダーを使用してService2にHTTP GETを送信できます。

• Service2は、リソースが最初にアプリケーションに返された後に変更されていないことを検出すると、アプリケーションがキャッシュ内のデータを使用できることを示すHTTPステータス304（変更されていない）の空の応答を返します。
• データが更新されている場合、Service2は新しいETagヘッダー（およびHTTPステータス200）を持つ新しいリソースを返します。

この方法は、リソースが変更されたかどうかを確認するためにHTTP GETを気にかけていない場合や、Service2でリソースが変更されたかどうかを（ロードする必要なしに）

利点は、Service2がそのクライアント（アプリケーション）のキャッシュを無効にする必要がないことです。非常に良い方法ではないかもしれません（クライアントが多い場合は難しいかもしれません）。