我有一個應用程序需要來自Service2的數據，它將永遠返回給定請求的相同答案，除非其後備數據庫已更新。數據庫很少更新，我們每年說兩次。如何正確設計一個restful API來使緩存失效？
我想設計一個解決方案，以便應用程序緩存Service2的答案，但要從外部提供一個功能，以使應用程序的緩存失效。我想從應用程序中暴露一個RESTful Web服務，但是我對如何正確設計它感到困惑。
/application/cache/invalidate是一個非REST式網址 - 我在考慮用HTTP POST調用/application/cache/。但是，在我看來，對於適當的RESTful設計，當POST用於更新資源時，要更新的內容應包含在請求的主體中。
什麼是正確的方式來設計一個「InvalidateCache」寧靜的web服務？
考慮使用POST和網址DELETE代替：
/application/cache/
在REST，兩者PUT和DELETE被認爲是indempotent行動。也就是說，它們可以用相同的最終資源狀態重複多次。在這種情況下，您的緩存是資源，並且多個DELETE將導致相同的狀態，一個清除的緩存。
您可以考慮在您的url中添加一個描述符，以闡明您正在清除緩存的內容，而不是刪除緩存對象本身。像
/application/cache/contents
也許，但這取決於你。如果有必要，去那條路線也可能讓你有選擇地從緩存中刪除。
這可能不會直接回答你的問題，但你可能也想看看HTTP ETags，這很適合在RESTful設計中緩存。
這個想法是，應用程序將從Service2獲取資源，該資源將與ETag頭一起返回資源（可能是最後修改的時間戳或散列）。然後，應用程序將隨同ETag一起緩存該資源。
當應用程序需要再次使用該資源時，它可以使用它在緩存中具有的ETag標頭髮送HTTP GET到Service2。
這種方法效果很好，如果你不介意的HTTP GET，看是否改變了資源，如果它很容易客服2可以確定資源是否發生了變化（而無需加載它）。
其優點是Service2不必使其客戶端（應用程序）的緩存無效，這可能不是一個很好的做法（如果有很多客戶端可能很難做到）。
優秀！在DELETE發佈後，緩存是否自動重新生成，是否符合REST？ – Edmondo1984
是的，沒有什麼可以阻止另一位演員修改緩存。從另一個角度來看，比如說你在緩存中暴露了一堆PUT值，並且在DELETE之後立即發生了PUT。在該序列之後，緩存不會爲空，但每個REST操作的結果都是有效的。 –
我一直想知道的是如何正確支持需要實時數據的管理員門戶，同時還支持面向客戶的應該獲取緩存數據的網站。 –