我們正在實作一個 RESTful API，我們有一個看起來像這樣的 POST 請求，/v1/systems/{systemId}/subsystems主體看起來像這樣
{"id": 0, "systemId": 0, "name": "string"}。這是變數的重復嗎？像這樣擁有它是一種好習慣嗎？
uj5u.com熱心網友回復：
URI 作為一個整體是資源的識別符號，而不僅僅是最后一部分。URI 本身是否遵循某種結構設計也取決于您的設計決策。就其本身而言，類似 URI 的 URI.../systems/{systemId}/subsystems不一定宣告它是systems集合的一部分，其父資源由各自的systemId. 只有當客戶端自然地探索總共跨越建立這種關系的樹的 URI 時，這才會“發展”。但是，這種關系通常用鏈接關系來表示，例如up參考父資源、item集合中的特定專案、subsection集合資源的子部分等等。查看Iana 的鏈接關系注冊表是否有適合您需要的鏈接關系。如果沒有可用的鏈接關系滿足您的需要，您可以向 Iana 注冊新的鏈接關系，或者使用Web 鏈接關系擴展，您可以在其中定義自己的命名空間中的私有關系。
關于systemId在使用 URI 結構（其中systemId已在路徑中使用 來標識父資源）時在正文中添加，該資訊顯然是多余的。但是，您是否想將它仍然包含在有效載荷中是您的設計選擇。包含或不包含它并沒有錯。
不幸的是，關于subsystems資源的資訊相當有限。給定的當前有效負載可能會減少到名稱本身，因為systemIdURI 中給出了id，并且子系統資源的 可能是自動生成的，而不是由客戶端定義的。因此，有效載荷將減少為單個名稱。在這里，您還可以避免創建子資源，并system通過將其設計為名稱陣列來對條目本身內的子系統名稱進行建模。在這里，您可以簡單地為系統資源（通過 Patch）提供一個更新方法來將名稱添加到該陣列，而不是創建子資源。但同樣，這是您的設計。任何對你有用的東西在這里都很好。
根據經驗，是否在有效負載中包含此類資訊，您可以以 Web 為例。即，如果 ID 應該是呈現給最終用戶的表示的一部分，則將其放入。如果不是，則將其省略。想想你想在頁面上呈現的產品。有時，如果您想為客戶提供一種獨特的方式來解決該特定產品的問題，那么如果存在相應的 productId 可能會有所幫助。然而，由于資源識別符號不應該盡可能改變，因此將 UUID 公開為內部產品識別符號并攜帶客戶應在其他欄位中使用的產品識別符號可能更有益。我們的一個客戶曾經進行過一次合并，在這次合并中，他們基本上合并了來自兩家公司的產品，這些公司的資料庫中都有不同的識別符號。結果，即使產品（以它們的真實形式）根本沒有改變，他們也不得不修改很多資源 URI。因此，不幸的是，某些客戶突然無法訪問以前添加書簽的產品說明等，因為沒有重定向。這肯定是一種極端和罕見的情況，盡管它可能會發生，如果您使用的設計支持這種設計更改，那么對整個系統的影響就不會那么顯著。
因此，長話短說，這取決于您的設計是否systemId是冗余資訊，或者您是否想將該資訊添加到有效負載中，或者甚至完全避免使用子資源，而是在父系統本身的串列中攜帶名稱。這里沒有正確或錯誤的答案。
uj5u.com熱心網友回復：
通常，不會通過 POST 將資源創建到指向單個資源的 URL。對于 GET、PUT 或 DELETE，您的 URL 看起來更正確。
在不知道您的確切要求的情況下，可以這樣做：
POST body {"systemId": 0, "name": "string"} to /v1/systems or /v1/subsystems
回應可以包含創建的子系統以及新的 id。
轉載請註明出處，本文鏈接：https://www.uj5u.com/yidong/328433.html