唯一約束在一個RESTful架構

Question

擁有15年的有狀態的客戶端 - 服務器的軟件開發經驗（和它的固有的問題），我還在努力掌握無國籍的概念在RESTful架構。

假設我有一個通用接口來發布業務對象到我的REST服務。例如用戶資源。我的用戶資源應該對他的電子郵件地址的唯一性有一個限制。我最初的反應是使用底層的數據庫設施來「渲染」這一點。第二個反應是引入一些鎖定或交易機制。

但我的Restafarian同事迴應：'不！客戶應該檢查新用戶的電子郵件是否是唯一的，並且您應該接受這樣一個事實，即可以插入重複電子郵件地址的時間窗口很小。客戶端應用程序應該能夠處理這個衝突。

這反過來違背了我學到的一切，一點都不自然。請賜教...

Answer 1

我看不出有什麼理由不返回相應的HTTP code：409衝突。這可以從您的數據庫中獲取錯誤返回。

這是很好的可用性原因檢查電子郵件地址是發送，你可以提示用戶（和禁用提交）糾正問題的請求之前唯一的。在任何情況下，服務器端驗證仍被建議。

Answer 2

這與協議無狀態無關。無狀態只說服務器不應該是一個保存會話相關狀態（http://en.wikipedia.org/wiki/Stateless_protocol）。

在你的情況下，用戶資源沒有會話狀態 - 它們是存儲在由服務器暴露的持續資源。沒有理由強制客戶端執行此檢查（通過迭代獲取並檢查所有用戶資源），並且使服務器執行此操作更有意義。無論這種檢查是由服務器作爲發佈新用戶資源的一部分完成的，還是存在單獨的資源來啓用此檢查 - 它本質上沒有區別，因爲服務器正在以這種方式進行檢查。如果您使用單獨的資源首先檢查是否可以發佈新用戶，然後發出新請求以實際執行POST - 那麼可能會出現重複的電子郵件地址。在這種情況下，預期的行爲是服務器通知客戶端POST請求失敗（使用適當的HTTP響應代碼，就像客戶端檢查電子郵件是否正確的第一個請求一樣）。

簡而言之：服務器的「檢查」，並在客戶端應該能夠處理在服務器通知它的檢查失敗的情況。