我正在创建一个宁静的网络服务。作为JPA我使用Hibernate。 我有像Country，City，Store，Sale等实体。
在长度和嵌套方面使用这样的URI是个好主意：http://example.com/countries/{countryId}/cities/{cityId}/sales/{saleId}/article/{articleId}？
是否有任何嵌套规则？我的意思是对的数量＆＃34; entity / {entityId}＆＃34; ？
答案 0 :(得分：1)
URI是不透明的。至于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，并专注于他们关心的部分。
所有唯一的硬限制是实际URI大小限制，除此之外，没有那么多严格的规则作为考虑设计中权衡的利弊。