REST風格的資源層次

Question

如何定義哪個資源是頂級Rest資源（URI不嵌套在任何父級中）？

我的問題來自這樣一個事實，如果我從字面上理解資源層次的概念，最終會得到很長的URI，比如5或6個層次。

這違背了REST的簡單性原則，而且，沿鏈的所有ID都是唯一的，所以可以簡化/縮短。此外，像Twitter或Facebook這樣的大型REST API，並不直接遵循層級規則。

Answer 1

REST中沒有規律。

確實恰恰相反：URI是不透明的，這是一個REST原則，因此URI <http://example.net/careers/technical/it/computing/programming/webProgramming/asp.net>從REST角度傳達的信息不如<http://example.net/fasd12>。

請注意，從REST角度來看，這兩個URI同樣不透明。一個給定的過程（數字或人類思想）可能會以一種特定的方式解釋前者，但在服務器另有說明之前，這種解釋不會是正確的（單從URI看，他們都無法知道它們都能識別Web服務來幫助預測一羣山羊的產奶量）。

凡層次進來是：

1. 如果服務器告訴客戶如何構建一個URI（如HTML的形式，將客戶端，或描述如何URI的其他格式上執行JavaScript的建成）。
2. 如果服務器使用相對URI來描述鏈接，作爲HATEOAS原則的一部分。

特別是後者，層次結構可能非常有用。

並且在這種情況下，如果您建立的是一組資源，它們之間的層次關係是5,6或14級，則具有5,6或14級深度的URI是很有用的。而不是其他。

在這種情況下它不違反簡單的任何原理：

1. ..作爲相對URI引用是很簡單的，無論是從1級深爲0，或43倍的水平要深到42 。
2. ./programming/作爲相對URI引用是很簡單的，無論是從0電平去深爲1，或42級深至43
3. 外給定上下文的諸如相對引用使用，所有的URI是同樣不透明，因此也同樣簡單：它們都是可以相互比較的字符串ith彼此，沒有別的。

編輯：

相反，儘管沒有理由擔心深層次，沒有理由感到感激他們要麼。如果將/a/b/c的資源作爲複合資源包含在/d之後，則對您更有用。也可以同時執行這兩個操作，其中/a/b/c/d和/e都標識相同的資源（一個301到另一個會導致更好的緩存行爲並使關係明確）。