2015-06-09 64 views
1

創建用戶時,我們發送用戶信息,在數據庫中創建用戶(所以現在用戶具有唯一標識)並執行信用檢查。如何標記REST中資源需要更多信息

如果a)用戶的信用評分高於某個數字,則一切正常(201)。 b)如果不是,我們需要用戶提供更多信息。

將採取什麼樣的方法來處理b。

感謝

回答

2

你仍然應該返回OK/HTTP狀態200或創建/ 201據我理解你的問題你的新用戶將被創建無論如何,只是後續的信用檢查可能會失敗。但服務器端和客戶端按預期工作。這是唯一重要的事情。如果客戶端出現問題,您只能使用4xx,例如用戶在數字字段中使用了一個字符串。您不能使用5xx,因爲服務器端沒有任何問題,例如您的信用服務有例外。您的信用服務失敗以及用戶需要更多信息的實際信息應該放在HTTP響應的正文中。

+0

我想我自己的答案寫得太快了。當然,如果行動(部分)成功,不應該使用'400'。我刪除了我的答案,贊成你的。 – slartidan

+0

那麼UI如何知道顯示哪條消息? – special0ne

+2

HTTP狀態碼的粒度不足以映射到更具體的錯誤消息。就像我爲更詳細的內容所建議的那樣,你應該把它放在HTTP響應的主體中,例如在包含其他錯誤代碼或錯誤消息的JSON對象中。 – Kris

2

在目前的形式下,信用檢查聽起來更像是RPC操作而不是RESTful資源。儘管信用檢查可能會調用某個銀行的REST API,該銀行返回credit-worthy或不作爲查詢的結果,但這不是非常RESTful,包括對用戶創建過程(IMO)的檢查。

因此,b)並不是真正的RESTful,它並不處理資源,而是執行一個類似於RPC的操作(信用檢查)。

你基本上這裏有兩種選擇:

  • 定義整個過程原子和強制性申報信用屬性和創建用戶只有當也是他支付/信用卡/ ...選項可供選擇,並積極檢查(返回400如果有任何缺失或檢查失敗)
  • 從拆分用戶創建信用檢查

對於後者,你應該獨立於用戶創建的信用檢查。在成功創建用戶時,返回201(與您一樣),並使用客戶端可用於執行下一個任務的額外鏈接(HATEOAS)。

由於信用檢查本身並不是真正的RESTful服務的候選人,因爲它本身不是一種資源,而更像是一種類似於RPC的操作(如已註釋過的),您可能希望將此代碼重構爲可能Spring注入到這些資源處理程序中的管理服務bean,這些資源處理程序需要信譽良好的用戶。

您還可以提供一個資產負債表(/api/users/1234/balance),用戶可以查看其當前餘額並獲得用戶可以用來進一步操作的行爲(以鏈接的形式)(例如向自己的餘額中添加更多資金,等等) )。

如果f.e.用戶嘗試訪問/api/article/yxz並且本文要求用戶有一個積極的餘額,如果用戶沒有足夠的錢,您可以返回402 Payment Required

+0

有趣的想法。謝謝 – special0ne

+0

我同意從信用檢查中分離用戶創建是一個好主意。我不同意信用檢查應該是RPC。它可以像使用某個參數的GET一樣簡單,或者如果它是複雜/異步的,它可以是POST來創建單獨的信用檢查資源。 (實際上,我相信大多數金融機構實際上會認爲信用檢查足夠重要的活動來保證自己的可記錄記錄。) – mahemoff

+0

@mahemoff謝謝你糾正我的拼寫問題:)我沒有說它必須是RPC,我剛剛提到過這聽起來更像舊式的RPC,我在開始時也舉了一個RESTful check-credit的樣子 - 儘管如此,仍然有每個用戶參考OP的操作 - 這就是Roy Fielding所主張的關於今天大多數「REST」服務,他們仍然像RPC一樣行事。 –