防止REST客戶

Question

考慮Spring MVC的Java Web應用程序，它提供了一些REST API。

假設它有很多方法，其中之一是DELETE /api/foo/{id}，它顯然從數據庫中刪除foo實體，給定的id。

的問題是，由於DB大數據，這個操作不是即時的，因此，如果客戶端嘗試同時執行多重刪除同一實體操作，說

DELETE /api/foo/123 X N次（錯誤地在客戶端軟件當然），

，它引起了一些DB令人不快的副作用（你知道，如果你嘗試在幾個交易刪除同一實體，這不是一般的好看）。

我的問題是：什麼是Spring MVC的最佳實踐，以防止這樣的情況呢？

我當然可以在每個這樣的更新方法（PUT/DELETE）中引入Foo id的同步。我將需要爲所有實體和所有PUT/DELETE API方法做到這一點，但我真的不想這樣做。我想這應該是一些優雅而又不錯的解決方案，如何在攔截器/ servlet級別上執行這種類型的同步，即不在控制器級別的服務上。

我還可以創建特定的攔截器，並執行那裏等着重複請求（有相同的URL和參數請求）。但是，這聽起來並不是一個優雅的解決方案（直到我將確保無法以更美觀的方式在Spring MVC中進行配置）。

Answer 1

這是一個併發問題，應通過使用適當的事務和鎖定級別來處理。不幸的是，在這裏沒有單一的規模，根據你的實際需求，你可能必須實現樂觀或悲觀的鎖定，以及可能的事務級別之一（從沒有事務到可串行化事務）。

一般情況下，在網絡層面處理這種問題是一個糟糕的主意，因爲你會喜歡什麼就做要求的提問要刪除一些數據，另一種是在同一時間顯示？在SpringMVC中，常用的方法是在服務層使用事務方法。另外，您應該在持久層中聲明一個樂觀或悲觀的鎖定系統。

樂觀層通常給出更高的吞吐量，在異常終止某些交易的成本。在這種情況下，目前的最佳做法是向用戶報告問題，要求他/她再次發送他/她的請求。