7
一個RESTful，hypertext-driven系統需要使客戶能夠創建一個新的資源，這個資源依賴於三個或更多不同類型的資源。公開此功能的最佳方法是什麼？REST：如何創建一個資源取決於三種或更多不同類型的資源？
舉一個例子，假設我運行在線商店。該服務器可以識別四種資源：
- 訂單：要運集團的產品。 [有一個貨件]
- 目的地：要運送到的位置。 [有很多貨件]
- 裝運：將產品發送給客戶的行爲。 [屬於目的地，訂單和打包者]
- 包裝員：員工在物理上準備裝運訂單。 [有很多貨件]
訂單發貨時，客戶需要通過在服務器上創建一個新貨件來記錄此事件。該貨件需要參考目的地，訂單和打包機。
要實現新的出貨量創造，我能想到的三種方法，而且我不喜歡任何人：
- POST使用裝運媒體類型/出貨。貨運媒體類型有三個字段：「order_uri」; 「packer_uri」;和「destination_uri」。每個URI分別用作裝運中涉及的訂單，打包機和目的地的唯一標識符。
- 使用貨運媒體類型發佈到/ orders/{order_id}/packers/{packer_id}/destinations/{destination_id} /貨件。
- 向系統中添加一個名爲「ShipmentBuilder」的新資源。使用ShipmentBuilder媒體類型中包含的「packer_uri」，「destination_uri」和「order_uri」POST到/ shipment_builders。
我不喜歡選項1，因爲Shipment媒體類型另外定義了指令，打包器和目標的鏈接。這裏，「鏈接」是由人類可讀名稱，URI和媒體類型組成的JSON哈希。將「order_uri」，「packer_uri」和「destination_uri」添加到媒體類型看起來不太乾燥，因爲它複製了關聯資源的URI。
選項2使用深層嵌套的URI，既不看起來很維護也不捕獲任何有意義的分層信息。
選項3在客戶端和創建貨件之間提供了另一個抽象層次，這使得系統難以學習。
如果貨件只依賴於另一個資源，則選項2會更有意義，但在這種情況下它不適用。就目前而言，我贊成選項3，但更喜歡更好的東西。
在這個例子中，創建新貨件的URI和媒體類型的最佳組合是什麼？還應考慮哪些其他方法？
更新：以下是貨件資源的JSON示例表示，顯示訂單，包裝員和目的地的鏈接。在「出貨」散列通過選項1出現所需的URI複製：
{
"shipment":{
"created_at": "Wed Sep 09 18:38:31 -0700 2009",
"order_uri":"http://example.com/orders/815",
"packer_uri":"http://example.com/packers/42",
"destination_uri":"http://example.com/destinations/666"
},
"order":{
"name":"the order to which this shipment belongs",
"uri":"http://example.com/orders/815",
"media_type":"application/vnd.com.example.store.Order+json"
},
"packer":{
"name":"the person who packed this shipment",
"uri":"http://example.com/packers/42",
"media_type":"application/vnd.com.example.store.Packer+json"
},
"destination":{
"name":"the destination of this shipment",
"uri":"http://example.com/destinations/666",
"media_type":"application/vnd.com.example.store.Destination+json"
}
}
的「貨物」散列的內容（以下「created_at」字段中）將得到公佈。使用GET時，上面的完整貨件表示將被髮送。
您能否詳細說明爲什麼您覺得向發貨媒體類型添加URI似乎不是DRY？我不明白你指的是什麼重複。 –
Darrel，在底部添加了一些東西。 –