我有一個Web Api REST風格的服務,它有幾個POST端點來插入一個新的對象到數據庫。我們希望將對象名稱接受的最大字符數限制爲20.數據庫,API或UI是否應該處理此問題?REST api管理字段的最大字符數的最佳做法是什麼?
顯然,我們可以在任何這些圖層上阻止超過20個字符。但是,如果它通過UI,則表單已提交。在那一點上,我們希望服務層或數據庫層返回一個關於爲什麼不被接受的信息性解釋。處理這個問題的最佳做法是什麼?
我有一個Web Api REST風格的服務,它有幾個POST端點來插入一個新的對象到數據庫。我們希望將對象名稱接受的最大字符數限制爲20.數據庫,API或UI是否應該處理此問題?REST api管理字段的最大字符數的最佳做法是什麼?
顯然,我們可以在任何這些圖層上阻止超過20個字符。但是,如果它通過UI,則表單已提交。在那一點上,我們希望服務層或數據庫層返回一個關於爲什麼不被接受的信息性解釋。處理這個問題的最佳做法是什麼?
DB,API或UI應該處理這個問題嗎?
最起碼,你的API 必須處理數據驗證。每個人對REST應該如何工作都有自己的看法,但是一種好的方法是返回HTTP 400(錯誤請求),其中一些內容包含關於爲什麼請求不好的信息。
除此之外,客戶端檢查是一項明確的獎勵。理想情況下,您甚至無法看到此代碼在您的API層遇到。客戶還應該能夠以優雅的方式處理潛在的「錯誤請求」響應。如果API和客戶端應用的規則不匹配,您需要客戶端認識到其操作未成功,並顯示適當的錯誤以幫助用戶響應該問題。
如果您允許數據通過批量導入或其他方式繞過API層,數據庫級檢查也是一個好主意。如果沒有,那麼如果您更改了驗證要求,數據庫可能只是您需要記住更改的另一個地方。
難道所以一個簡單的驗證字符串不超過20個字符應該是有效的?只要立即返回一個錯誤的請求響應的UI以防萬一它通過?這正是我所傾向的,但如果處理它的服務沒有意義,我不想添加冗餘代碼。 – LeythG
@LeythG:對。請記住,您無法控制API以外的任何內容,因此惡意用戶可能會嘗試傳送巨大的有效內容以惹惱您。或者有些人可能會在某天針對您的API編寫另一個客戶端(例如,用於移動應用程序),並忘記包含此檢查。或者,當您升級客戶端庫時,可能會引入一個缺陷,導致您的客戶端無法執行應該執行的驗證。 API層是您控制這一點最重要的一點。 – StriplingWarrior
這很有道理,非常感謝您的迴應和幫助。 – LeythG