如何組織REST API？

我正在爲我們的業務系統開發一個休息API。我們有以下的資源至今：如何組織REST API？

/sales/orders 
/sales/orders/{orderno} 
/sales/order-items

將會有大量的資源時，API完成，因此我們需要構造它的一個好辦法，使之易於理解。我的問題是：應該/sales/order-items而不是/sales/orders/order-items？這裏可能沒有正確的答案，但你更喜歡什麼？

還有一個問題：sales/order-items資源將列出所有未清項目或所有已發貨項目。它將而不是可能獲得所有訂單項無論狀態（打開/運送）。資源URI可以是這樣的sales/order-items?orderstatus={OPEN/SHIPPED}（那麼orderstatus查詢參數將是必需的），或者它可以是兩個資源，例如sales/order-items/open和sales/order-items/shipped。什麼是首選？

來源

2012-09-26 rgullhaug

要明確：在/銷售/最終會有很多資源。 Like/sales/customers，/ sales/contracts，sales/quotes – rgullhaug

有點不清楚/ sales/order-items資源實際是什麼。它將給出所有訂單項目的清單，而不管其所屬的訂單。爲了僅獲得特定訂單的商品，還會有這樣的資源：/ sales/orders/{orderno/items – rgullhaug

資源是'任何可以命名的信息'。你的URI應該是基於實體的。 '訂單項'不是一個實體，而是一種數據類型。

/sales/order/order-1456321是您最有可能需要的實體。其中將包含所有訂單商品的數據。

如果您希望限制訪問，如果未提供查詢字符串，則可以返回客戶端錯誤。並有

/sales/order/order-12345?status=open

等希望這會有所幫助。

編輯：

/sales/order-items or /sales/orders/order-items?

這是特定領域，真正應該由領域專家來回答。您的URI層次結構爲您的資源提供了範圍（以及其他細節）。因此，作爲一個有教養的猜測，「訂單項」在「/ sales/orders /」範圍內是沒有意義的，因爲「訂單項」不是「訂單」。

/sales/ordered-items

似乎是最明智的答案。

對個人筆記而言，不要過多質疑您的域名，強烈理解存儲的業務和信息的流向可能會導致與這些建議相符的內容;

/sales/orders?status=open - Are all orders shipped at once? 
/sales/orders/order-1234/packages?status=open - Are orders split into packages?

來源

2012-09-26 14:32:40

我對於銷售/訂單物品的真實性不是很清楚。/sales/orders/{orderno}/items將爲特定訂單提供所有商品，但/ sales/order-items將提供所有訂購商品的列表，無論訂單如何。然後一個訂單項是一個實體，就像訂單是一個實體一樣。 – rgullhaug

啊，是的，我現在明白了;我將編輯我的回答 –

你可能是對的。訂單商品不是訂單，但訂單商品屬於訂單。一個訂單可以有1到多個訂單項。無論父母訂單如何，都可以使用銷售/訂單項檢索訂單項。所以我覺得將訂單項下放到這樣的訂單下並不是完全錯誤的，例如this/sales/orders/order-items。我希望將它置於命令之下的唯一原因是爲我的API創建更多結構，以便與訂單有關的所有內容都位於/ sales/order下，但這可能不是一個好主意？ – rgullhaug

如何組織REST API？

回答

相關問題