最佳實踐 - 由兩個名稱標識的資源的REST URI設計

REST資源應由兩個名稱標識。最佳做法是什麼？最佳實踐 - 由兩個名稱標識的資源的REST URI設計

我的想法：

.../{id1}-{id2} 
.../{id1}/{id2}

一個ID可以由數字，字母和特殊字符。

第一溶液：

如果ID中的一個包含字符-出現問題。在這種情況下，分隔字符不是唯一的。

解決方法二：

在剛剛.../{id1}就沒有資源，這是REST風格的？

編輯：

的REST資源表示憑據。憑證由提供者名稱和用戶名標識。

.../Credentials/<ProviderName>;<UserName>

我不想在.../Credentials/<ProviderName>顯示供應商的所有憑證（它不會適合我的XML結構）。

編輯2：

在.../Credentials所有憑據將在XML顯示。憑證是以XML根元素的子元素表示的。我想創建一個與XML結構相同的REST資源結構。因此，.../Credentials的子資源應該直接是某個證書（而不是像所有提供者那樣的一組證書）。

來源

2013-04-08 user1056903

你能詳細說明2個名字的含義和這些ID代表什麼嗎？如果你提供一個例子來給出更多的上下文，那會更好。 – 2013-04-08 10:05:47

編輯我的第一篇文章。 – user1056903 2013-04-08 11:08:56

你可以更具體地說明你想要讀取最後一個url的內容嗎？如果不是提供者的所有證書？ – Twissell 2013-04-08 11:16:12

你的第二個解決方案.../{id1}/{id2}說，對我說，你有id1和id2之間的層級關係，這似乎是因爲兩個標識引用相同的資源，就像你說的不修復得非常好你的資源的設計。在另一方面，你先解決.../{id1}-{id2}可以使用;代替-避免暗示層次結構中沒有這樣的在Restful Web Services引用，所以我會用這個去：

.../{id1};{id2}/

來源

2013-04-08 09:48:57 Twissell

Annotation @Path（「{id1}; {id2}」）似乎不適用於Jersey。 – user1056903 2013-04-08 11:39:33

REST API必須是超文本驅動，所以不要浪費你的時間在URL模式上，因爲它們不是RESTful。 URL模式暗示着客戶端和服務器之間的緊密耦合;簡而言之，客戶端必須瞭解URL的外觀以及構建它們的能力。

也看到這個職位：

http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

注意有關憑證;看起來你保持了客戶端和服務器之間的狀態，這也違反了REST原則：無狀態。

來源

2013-04-08 15:55:13 filip26

最佳實踐 - 由兩個名稱標識的資源的REST URI設計

回答

相關問題