REST - 如何使用複合鍵設計URI？

我有一個關於如何用複合鍵設計資源URI的問題。REST - 如何使用複合鍵設計URI？

我有一個稱爲貨運的資源，它有4個鍵/ ID：合作伙伴ID，最初的郵政編碼，最終的郵政編碼和重量。

其實我的資源被設計成具有通過數據庫生成一個增量的ID，但這種方法是不是那麼好API的消費者，例如，如果一個消費者/合作伙伴需要更新他們所要做的貨運信息：

？

GET貨運initialZipcode = {VALUE} & finalZipcode = {VALUE} &重量= {VALUE}

的操作的響應以上將是貨運ID，所以最後他們可以更新信息：

PUT貨運/ {ID}

合作伙伴ID由認證機制隱含。

對我來說，在更新信息之前，似乎奇怪的是合作伙伴要獲得運費ID。

所以我的問題是：我如何設計這個URI？

PUT貨運/ initialZipcode/{價值}/finalZipCode/{價值} /重量/ {價值}

我是否考慮上面的設計？

另一個問題：是否將partnerId嵌入認證機制是一種很好的做法？我知道專家（對消費者而言容易）和缺點（緩存，不可能共享URI等），但我不知道一般是好還是壞的做法。

謝謝！

來源

2013-12-17 Krock

沒有什麼錯

PUT freight?initialZipcode={VALUE}&finalZipcode={VALUE}&weight={VALUE}

查詢參數的資源標識的一部分了。

路徑參數對於定義適合層次結構的資源非常有用。在你的情況下，資源不適合層次結構，所以不要試圖將參數壓縮到路徑段中。

唯一的挑戰是當客戶端重新排列查詢參數的順序時要做什麼。你是否將它視爲同一資源，還是404？如果你沒有緩存GET響應，那麼它可能沒有關係。

如果您爲您的客戶提供了一個URI模板供他們填寫，那麼他們會以錯誤的順序爲您提供參數的可能性較小。

另一種選擇，如果你與你原來的建議去是你的GET返回重定向和Location頭到URI與貨運ID。例如

GET freight?initialZipcode={VALUE}&finalZipcode={VALUE}&weight={VALUE} 
=> 
302 See Other 
Location: freight/1232321322

通過這樣做，你的客戶不必知道貨運ID任何東西，它可以只搶到位置標頭，並按照重定向做一個GET，或者直接做PUT反對任何URI位於「位置」標題中。這意味着如果您決定不再公開此ID，則可以在不中斷任何客戶端的情況下更改URI。

來源

2013-12-17 14:40:32

嗨達雷爾，謝謝你的回答。對我來說，你的（第一）方法似乎很奇怪，因爲我總是使用ID的概念，而不是像你展示的那樣用作查詢參數。對於我來說，查詢參數決定了特定資源中的額外選項，例如：過濾器，搜索，排序，分頁等。我在API中有其他一些情況來更新資源，並且在所有操作系統中， URI（路徑參數），所以如果我有其他情況下的更新是帶參數的，我覺得我傷害了統一接口的概念。我錯了？ – Krock

@Krock RFC 3986指出查詢參數是資源標識的一部分。它們不是一些額外的元數據。這是從以前版本的URI規範中作出的澄清。 http://tools.ietf.org/html/rfc3986#section-3.4客戶端應該將整個URI視爲不透明的標識符。 –

你說服了我:) 但在創建一個新的貨運的情況下？我怎樣才能返回迴應？使用身份證件時，回覆將作爲創建運費的「地點」（例如：運費/ ID），但是如果我沒有身份證件，回覆是什麼？貨運地點？initialZipcode = {VALUE}＆finalZipcode = {VALUE}＆weight = {VALUE}？ – Krock

REST - 如何使用複合鍵設計URI？

回答

相關問題