17

Service2 からのデータを必要とするアプリケーションがあります。このアプリケーションは、指定された要求に対して同じ応答を永遠に返します。そのバッキング データベースが更新されない限りです。データベースはめったに更新されません。たとえば、年に 2 回です。

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

/application/cache/invalidate/application/cache/は非 RESTful URLです。HTTP POST で呼び出されることを考えていました。ただし、RESTful な設計を適切に行うには、POST を使用してリソースを更新する場合、更新するコンテンツをリクエストの本文に含める必要があるように思われます。

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

4

2 に答える 2

18

URL のDELETE代わりに使用することを検討してください。POST

/application/cache/

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

URL に記述子を追加して、キャッシュ オブジェクト自体を削除するのではなく、キャッシュの内容をクリアすることを明確にすることを検討できます。何かのようなもの

/application/cache/contents

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

于 2012-11-08T16:21:28.553 に答える
6

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

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

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

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

このアプローチは、HTTP GETを気にせずにリソースが変更されたかどうかを確認し、Service2がリソースが変更されたかどうかを（ロードせずに）判断できる場合にうまく機能します。

利点は、Service2がクライアント（アプリケーション）のキャッシュを無効にする必要がないことです。これはあまり良い方法ではない可能性があります（クライアントが多い場合は実行が難しい可能性があります）。

于 2012-11-08T20:38:27.287 に答える