我一直在處理這個問題很多次，在閱讀了不同的文章之后，我仍然不知道哪個是最好的方法
假設我有這個模型：
-作者 -類別 -書籍
沒有作者和類別，一本書就不可能存在，因此在談論創建新書的帖子端點時，我有四個選項：
myapi/v1/authors/{authorId}/category/{categoryId}/boooks（嵌套物體）
myapi/v1/{authorId}/{categoryId}/boooks （只是作為路徑引數的外鍵）
myapi/v1/books/?author={authorId}&category={categoryId}（使用查詢引數）
myapi/v1/books（使用包含作者和類別 ID 的請求 DTO）
這些選項中哪一個是最好的？選項 1 提供了有關關系的大量資訊，但隨著關系的增長，可能難以維護（非常長的 URI）
選項 2 和 3 對我來說看起來不錯，但我不知道這是否是正確的方法
選項 4 更易于閱讀和維護，但它沒有提供有關書籍 i 如何與作者和類別相關的資訊
我愿意接受建議。謝謝！
Trying to build a proper and readable post endpoint for a post rest api endpoint
uj5u.com熱心網友回復：
#4 在我看來。URL 不必提供有關您的資料結構的資訊
uj5u.com熱心網友回復：
我的回答是我們談論的是自定義方法，而不是像 OData 這樣的標準。
- 好的，如果你糾正了錯別字，如果你混合復數（作者、書籍）和單數（類別）形式，很難理解。
- 絕對不是，很難猜測和記住
- 好的
- 對于像這樣的簡單請求，使用 POST 或 SEARCH 沒有意義，最好將它們用于更復雜的搜索
我投第3個，因為作者和類別之間沒有等級關系。我猜一個作者可以發布到多個類別，一個類別可以包含多個作者，所以它是資料庫術語中的 n:m 關系。對于大多數情況，我喜歡第三種解決方案，因為它很簡單。如果您有資源的唯一 ID，那么它就是{type}s, /{type}s?filters={filters}, /{type}s/{id}, /{type}s/{id}/{property}。如果您有許多不同的資源型別，那么{type-group}/{type}s. 如果您不關心可讀性，過濾器可以被 JSON 序列化和 URI 編碼，畢竟對于機器來說它是可讀的。
大多數人沒有理解的是，webservice 是一個服務，它有消費者呼叫的操作，它不是一個資料結構。這些端點標識哪個操作將處理請求，而不是在資料庫中訪問哪個資料記錄。后一種是因為我們在談論某種型別的操作，但我可以輕松撰寫GET https://example.com/calendar/api/v1/time/now它，它根本不會觸及資料庫。
uj5u.com熱心網友回復：
我會選擇第四個選項。
myapi/v1/books（使用包含作者和類別 ID 的請求 DTO）
對于 POST 請求，根據經驗，在大多數情況下，使用請求 DTO 發送資料是一個很好的解決方案。
更重要的是，使用請求 DTO，將允許您使用相同的 api 進行單個創建或批量創建書籍，您只需在請求 DTO 中發送一個串列，即可在一次 api 呼叫中創建多個書籍。
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/524259.html