前言
問個 假如我今天有個表單在前端要送,然後我想要先檢查這個表單有沒有被其他人更新
這是在一次和朋友的討論中有人提出來的問題。
恩…這是很典型資料競爭的問題,但並不是多個執行緒存取一份資料,而是多個瀏覽器客戶端(Browser Client)存取同份伺服器資源。
通常,我們在討論RESTful - 一種當下很常見的Web API設計方式的時候,只會提到建立(Create / POST)、讀取(Read / GET)、更新(Update / PUT)、補充(PATCH)和刪除(DELETE),也就是一般的CRUD。甚少會在深度討論一些細節,就如開頭提到的問題。並且通常在瀏覽網站,也很少去注意各個網站的API設計方式。
那麼這個問題要怎麼解決呢?
不管怎麼說,伺服器上的資料正確性最終需要由伺服器處理保護。
可以簡單一些在資料上添加版本(Version)或最後修改時間(Last Update time)的欄位。當收到更新或刪除訊息,該欄位應該保持一致。不過這就會出現一個很奇妙的現象:
> GET /data1
< 200 OK
< Content-Type: application/json
<
< {"name": "Bob", "age": 18, "version": 1}
當我們有一個資料data1
其版本為1
,如果我們需要更新的話,下面的訊息代表什麼意思?
> PUT /data1
> Content-Type: application/json
>
> {"name": "Alice", "age": 18, "version": 1}
< 204 No Content
這是一個更新,版本是不是應該跳到2
?但是按照前述這個版本應該要與記錄一致才會被修改,但是這樣似乎又與PUT
的意圖衝突?
或許有一些設計是檢查更新版本-1
是不是與當前記錄版本
相同作為檢查判斷條件。但是想想,其實版本號的決定,似乎不該由Client傳進的資料決定,而應該由後端資料管理行為決定。
那麼來介紹另一種設計方式,其實HTTP一般性規範都幫你準備好了,只是在我經驗觀察上,似乎並沒有那麼易用(也可能是因為了解的人真的不多),並不經常看到這樣的設計。這可能會包含一些你可能不知道的HTTP狀態碼(HTTP Status Code)和HTTP Headers。