我想我會在這里發布一些關于我最近遇到的問題的想法/反饋。我開發的 API 對作為路徑引數傳遞的識別符號進行了驗證：例如 /resource/resource_identifier
關于使識別符號有效的原因有一些特定的業務規則，并且我的 API 具有執行這些規則并在違反時回傳 400 的驗證。
現在我寫這篇文章的原因是我在我寫過的每一個 REST (ish) API 中都在做這種事情。它現在在我心中根深蒂固，但最近有人告訴我這是“壞的”并且它破壞了封裝。此外，它通過強制消費者了解識別符號的格式來做到這一點。有人告訴我，我應該回傳 404 并簡單地接受任何東西作為識別符號。
關于這一點以及封裝在 REST 背景關系中的實際含義，我們進行了一些非常激烈的辯論。我找到了許多定義，但它們并不具體。與任何 REST 爭論一樣，很難證實兩者的論點。
如果 StackOverflow 允許我，我想嘗試對此達成共識，以及為什么像 Spotify 這樣的 API 在這種情況下使用 400。
uj5u.com熱心網友回復：
雖然將資源內部 ID 公開為 URI 中使用的 ID 聽起來很自然，但請記住，整個 URI 本身是資源的識別符號，而不僅僅是 URI 的最后一位。客戶端通常也不對構成 URI 的字符感興趣（或者至少他們不應該關心它），而只對他們從 API/服務器請求時收到的狀態感興趣。
此外，如果您從長遠來看，這應該是您希望在 REST 架構之上構建設計的原因，資源的內部識別符號是否有可能改變？如果是這樣，那么引入間接可能更有意義，即通過在 URI 中使用 UUID 而不是產品 ID，然后有一個進一步的表/集合來執行從 UUID 到域物件 ID 的映射。想一想公開產品某些資料的資源。在 URI 末尾使用產品 ID 聽起來可能是個好主意，因為它們可以清楚地標識您的域模型中的產品。但是，如果您的公司與另一家恰好在產品上有重疊但使用與您不同的識別符號的公司合并，會發生什么？不幸的是，我在現實中看到過這種情況，
這正是邁克阿蒙森說的原因
...您的資料模型不是您的物件模型不是您的資源模型...（來源）
REST 充滿了這樣的間接機制，以允許這樣的系統避免耦合。即除了上述機制之外，您還具有鏈接關系以允許服務器在需要時切換 URI，而客戶端仍然可以通過公開的關系名稱查找 URI，或者它專注于協商的媒體型別及其表示格式，而不是強迫客戶端說話他們特定于 API 的類似 RPC 的純 JSON 俚語。
Jim Webber進一步創造了這個術語domain application protocol來描述 HTTP 是一種用于交換檔案的應用程式協議，我們推斷的任何業務規則都只是 HTTP 執行的實際檔案管理的副作用。所以我們在“REST”中所做的基本上就是來回發送檔案并推斷一些業務邏輯以在接收到某些檔案時采取行動。
關于封裝，這不是 REST 和 HTTP 的范圍。您回傳的資料取決于您的業務需求和/或交換的表示格式的功能。如果某種媒體型別無法表達某種能力，那么向客戶端提供此類資料可能沒有多大意義。
一般來說，出于上述原因，我建議不要將域內部 ID 用作 URI 的一部分。通常，該資訊應該是交換的有效負載的一部分，以使用戶/客戶可以選擇在其他渠道（如電子郵件、電話等）上參考該資源……當然，這取決于資源及其手頭的目的。作為用戶，我更愿意用我的全名而不是一些內部用戶或客戶 ID 等來稱呼自己。
編輯：對不起，錯過了驗證方面......
如果您希望在服務器/API 端進行用戶/客戶端輸入，則應始終在開始處理資料之前驗證資料。通常，URI 由服務器提供，并且只有在請求的 URI 與您定義的規則之一匹配時才可能觸發業務活動。通常，大多數框架400 Bad Request在無法將 URI 映射到具體操作時都會做出回應，從而使客戶端有機會糾正其錯誤并重新發出更新的請求。由于 URI 無論如何都不應該由客戶端生成或更改，因此驗證此類引數可能是不必要的開銷，除非它們可能會引入安全風險。在這里它可能是一種更好的方法，然后將 URI 的映射規則加強到操作，然后讓這些框架在客戶端使用他們不應該使用的東西時回應 400 訊息。
uj5u.com熱心網友回復：
我在我寫過的每一個 REST (ish) API 中都在做這種事情。它現在在我身上根深蒂固，但最近我被告知這是“壞的”
在 HTTP 的背景關系中，它是一種“反模式”，是的。
我被告知我應該回傳 404
當您想要像通用 Web 服務器一樣回應的優勢時，這是正確的模式。
重點是：如果您希望 HTTP 應用程式中的通用組件能夠對您的回應訊息執行合理的操作，那么您需要為它們提供適當的元資料。
如果目標資源識別符號滿足RFC 9112中定義的請求-目標生產規則但在其他方面不令人滿意；你可以選擇任何你想要的回應語意（400？403？404？499？200？）。
但是如果您選擇 404，那么通用組件將知道回應是一個錯誤，可以重新用于其他請求（在適當的條件下 - 請參閱RFC 9111）。
為什么像 Spotify 這樣的 API 在這種情況下使用 400。
請記住：工程是關于權衡的。
快取的好處可能不會超過更具成本效益的請求處理，或者更有效的事件分析，或者......
也有可能只是習慣——這樣做是因為他們一直都是這樣做的；或者因為他們被教導為“最佳實踐”，或者其他什么。我們需要考慮的工程權衡之一是是否投資分析權衡！
一個不完美的船舶系統比一個完美的解決方案贏得更多的市場份額。
uj5u.com熱心網友回復：
當我們想要將資料和實作隱藏在介面后面時，封裝是有意義的。在這里我們要暴露資料的結構，因為它是用于通信的，而不是用于存盤的，服務當然需要這種通信才能運行。資料驗證是一個非常基本的概念，因為它使服務可靠并且可以防止黑客攻擊。這里的 id 是一個引數，檢查它的結構只是引數驗證，如果失敗應該回傳 400。因此，這不僅限于請求的正文，問題可能出現在 HTTP 訊息中的任何地方，如下所示。另一個反對 404 的論點是所請求的資源不可能存在，因為我們談論的是格式錯誤的 id 和格式錯誤的 URI。驗證每個用戶輸入非常重要，
超文本傳輸??協議 (HTTP) 400 Bad Request 回應狀態代碼表示服務器無法或不會處理請求，因為某些原因被認為是客戶端錯誤（例如，格式錯誤的請求語法、無效的請求訊息幀或欺騙性）請求路由）。
對比
HTTP 404 Not Found 回應狀態碼表示服務器找不到請求的資源。導致 404 頁面的鏈接通常被稱為損壞或死鏈接，并且可能受到鏈接腐爛的影響。404 狀態代碼僅表示資源丟失：而不是暫時的還是永久的。如果某個資源被永久洗掉，請改用 410 (Gone) 狀態。
在 REST 的情況下，我們使用 HTTP 協議、URI 標準、MIME 型別等來描述介面，而不是實際的編程語言，因為它們是獨立于語言的標準。對于您的具體情況，最好檢查包括 HATEOAS 約束在內的統一介面約束，因為如果您的服務按照應有的方式生成 URI，那么很明顯，格式錯誤的 id 是惡意的。對于 Spotify 和其他 API，其中 99% 不是 REST API，可能是 REST-ish。閱讀菲爾丁論文和標準，而不是試圖根據 SO 答案和示例來弄清楚。所以這是一個典型的 RTFM 情況。
在 REST 的背景關系中，一個非常簡單的資料隱藏示例是存盤一個數字，例如：
PUT /x {"value": "111"} "content-type:application/vnd.example.binary json"
GET /x "accept:application/vnd.example.decimal json" -> {"value": 7}
在這里，我們不公開我們如何存盤資料。我們只是發送它的二進制和十進制表示。這稱為資料隱藏。在 id 的情況下，擁有外部 id 并將其轉換為內部 id 是沒有意義的，這就是為什么您在資料庫中使用它的原因，但可以檢查其結構是否有效。通常您驗證它并將其轉換為 DTO。
在這種情況下，實作隱藏更加復雜，它有點避免對服務進行微管理，而是在頻繁發生時實作新功能。它可能涉及消費者調查，了解他們需要哪些功能，檢查日志并找出某些消費者發送過多訊息的原因以及如何將它們合并為一條訊息。例如我們有一個數學服務：
PUT /x 7
PUT /y 8
PUT /z 9
PUT /s 0
PATCH /s {"add": "x"}
PATCH /s {"add": "y"}
PATCH /s {"add": "z"}
GET /s -> 24
vs
POST /expression {"sum": [7,8,9]} -> 24
如果你想在結構化編程、OOP 和 REST 之間進行轉換，那么它是這樣的：
Number countCartTotal(CartId cartId);
<=>
interface iCart {
Number countTotal();
}
<=>
GET api/cart/{cartid}/total -> {total}
因此，一個端點代表一個公開的操作，verbNoun(details)例如countCartTotal(cartId)，您可以將其拆分為verb=countTotal、noun=cart，details=cartId并從中構建 URI。動詞必須轉換為 HTTP 方法。在這種情況下，使用 GET 是最有意義的，因為我們需要資料而不是發送資料。動詞的其余部分必須轉換為名詞，所以countTotal -> GET totalCount。然后你可以合并兩個名詞：totalCount cart -> cartTotal. 然后，您可以根據生成的名詞和詳細資訊構建一個 URI 模板：cartTotal cartId -> cart/{cartid}/total您就完成了端點設計GET {root}/cart/{cartid}/total。現在您可以將其系結到countCartTotal(cartId)或repo.resource(iCart, cartId).countTotal()。
所以我認為如果 id 的結構沒有改變，那么如果你愿意，你甚至可以將它添加到 API 檔案中。雖然沒有必要這樣做。
從安全角度來看，如果發送此類請求的唯一可能原因是黑客攻擊，您可以回傳 404，因此黑客無法確定失敗的原因，您也不會暴露保護的詳細資訊。在這種情況下，它會過度思考問題，但在某些情況下，它是有意義的，例如 API 可以在哪里泄漏資料。例如，當您發送密碼重置鏈接時，Web 應用程式通常會要求您提供電子郵件地址，如果未注冊，其中大多數會發送錯誤訊息。這可用于檢查是否有人在網站上注冊，因此最好隱藏此類錯誤。我想在你的情況下，id 不是敏感的東西，如果你有適當的訪問控制，那么即使黑客知道 id，他們也不能對這些資訊做太多事情。
另一個可能的方面是，如果 id 的結構發生變化會怎樣。好吧，我們撰寫了一個不同的驗證代碼，它只允許新的結構或者可能同時允許這兩種結構，并使用v2/api根v2/docs和檔案 URI 制作 API 的新版本。
所以我完全支持你的觀點，我認為你提到的其他開發人員甚至不了解 OOP 和封裝，更不用說 Web 服務和 REST API。
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/526122.html
標籤：休息