我正在创建一个宁静的网络服务。作为 JPA，我使用 Hibernate。 我有 Country、City、Store、Sale 等实体。
在长度和嵌套方面具有这样的 URI 是否是个好主意：http://example.com/countries/{countryId}/cities/{cityId}/sales/{saleId}/article/{articleId}？
是否有嵌套数量的规则？我的意思是“实体/{entityId}”对的数量？
【问题讨论】：
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 大小限制，除此之外，在您的设计中考虑权衡利弊并没有那么严格的规则。
【讨论】：