RESTful應用程序的正確長度是多少？

Question

我正在創建一個寧靜的web服務。作爲JPA，我使用Hibernate。 我有像國家，城市，商店，銷售等其他實體。

在長度和嵌套方面有這樣的URI是一個好主意：http://example.com/countries/{countryId}/cities/{cityId}/sales/{saleId}/article/{articleId}？

是否有嵌套數量的規則？我的意思是「實體/ {entityId}」對的數量？

Answer 1

URIs是不透明的。就HTTP和其背後的RESTful原則而言，http://example.com/countries/{countryId}/cities/{cityId}/sales/{saleId}/article/{articleId},http://example.net/sfdaikwjepfiaosnd和http://example.org/之間沒有區別，其後是Finnegans Wake的URI編碼內容。實際上，這三者完全可能是同一資源的URI，也許一個永久地重定向到另一個。

因此，這是非常重要的非REST問題。

其中之一是，如果你有風險去beyond practical size limits你會有問題。

另一種情況是，如果這些URI很小，那麼包含大量URI的實體顯然會更短。這通常不是一個大問題，但如果URI真的很大，並且每個實體在千字節的這種URI上都包含千字節，那麼它對網絡使用會產生一些影響。

另一個就是造型的用處：如果調用代碼不會在意它想要一篇文章時關注國家，那麼您的建模不會幫助調用代碼。

與此相關的是相對鏈接在幫助REST的HATEOS方面的實用性：如果您可能經常能夠將article/2作爲相關鏈接用於描述銷售的實體或（潛在的硬編碼）../../去描述從描述文章的銷售的實體，然後這是方便的。問題是你是否最有用的鏈接是最有用的。例如，如果從國家到城市比從國家到其他任何地方更普遍，那麼爲什麼有/cities/部分的路徑，而不僅僅是{countryid}/{cityid}？

這個相對鏈接問題可以解決導致大型實體的大型URI的問題：如果實體中的大多數URI與實體描述的資源「接近」，那麼大多數URI可以用非常小的相對URI來表示。

另一方面是這些ID是否適合人類讀者。是紐約的ID有點像193或類似NewYork或New%20York或者Nueva%20York？從REST的角度來看，這些都具有相同的價值，但193給出了較短的URI與上述優點，而其他人更容易處理作爲消費開發人員或調試時。

嵌套也影響這個人類可讀的方面。一方面，大量的嵌套可以使每個元素都很容易識別，但另一方面，混淆本身就可能導致路徑中有太多路段。儘管大多數情況下，如果分裂是可以理解的，那麼人類讀者可以過濾出大部分的URI並專注於他們關心的部分。

在所有唯一的硬限制是實際的URI大小限制，除此之外沒有太多嚴格的規則作爲利弊考慮設計中的權衡。