2016-11-16 68 views
0

我被要求爲前端團隊創建一個端點RESTfull,它將向我發送有關用戶表單的信息。REST API中的PUT和POST。它們只用於語義分離嗎?

有很多的場景,但我會解釋只有1個來試圖解決我的問題:

  1. 他們會送我一個包含了很多關於用戶數據的數組。例如userFirstName和userLastName。我需要檢查用戶是否存在於數據庫中。如果存在,請更新表單中發送的所有數據。如果用戶不存在,請在表中創建它,然後在所有相關表內創建與新用戶相關的信息。

    1. 如果PUT更新數據
    2. 後,如果插入數據

    我一定要告訴他們什麼動詞:

因此,在這種情況下創建一個端點時,我們可以有兩種可能性他們應該在調用我的端點時使用,如果是PUT或POST。 我可以給他們POST並在這個過程中做一些更新,或者我可以給他們一個PUT並做一些INSERT。

基於RESTfull標準,不應該這樣做。但除了最佳實踐標準(要語義化)之外,還有其他限制需要評估嗎?

+0

「任何其他約束要評估」 - 我不這麼認爲。兩者都會完成這項工作。看來,你在這裏不可能是純潔的。所以只需選擇一個並使用它。我建議POST更「通用」。 –

回答

0

基本上,當你想發送信息到服務器時,你應該使用HTTP方法POST。在我看來,你可以創建三個方法,POST方法來驗證用戶是否存在,以及可以在驗證後調用的INSERT和UPDATE方法。

0

PUT在HTTP中有一個非常具體的含義,那就是它表示一個資源表示的冪等置換。 From RFC 7231

PUT方法請求創建目標資源的狀態或用請求消息負載中包含的表示定義的狀態替換目標資源的狀態。

如果你把PUT消息的實體主體,從它從頭開始構建資源的一個新的演示文稿,然後替代以前的表現(認爲鍵值存儲),然後將是適當的。

在另一方面,如果你是合併與你已有的代表性,然後將請求主體提供的表示是合適。

菲爾丁,響應一個註釋It is ok to use POST,建議

我們只用PUT當更新的動作是冪等,並表示已完成。

在HTTP中,當其他方法都不合適時,POST是適當的方法,所以這就是您在此使用的方法。

但是......沒有理由不能擁有更多資源(更多uris),包括對資源進行的每個編輯都有唯一的uri。使用PUT創建一個新的資源作爲副作用也更新一些其他資源是一個完全可以接受的模式。這種新資源不一定非常耐用 - 您可以在副作用完成後儘快過期。

這爲您提供了PUT的冪等寫入語義,而不會違反HTTP施加的完整表示約束。

相關問題