我正在为我们的后端开发一个私有 API。
我的收藏有关联。
每个集合都可以请求，分页，也可以请求关联，对关联进行分页。
我们不确定要使用哪种 URL 设计……我们正在考虑：
/users.json?per_page=10&association=parts,auditions&parts_per_page=5&auditions_per_page=5
/users.json?per_page=10&association[]=parts&association[]=auditions&parts_per_page=5&auditions_per_page=10
/users.json?per_page=10&association[auditions]=true&association[parts][per_page]=5
你怎么看？你会选择哪一个？为什么 ？其中一个看起来不像有效的 url 方案吗？
谢谢！
【问题讨论】：
标签： ruby-on-rails http api rest restful-url
我的回答：/users.json。 HTTP 针对大粒度超媒体传输进行了优化；缓存是其中很重要的一部分，上面给出的 URI 方案都不是对缓存非常友好的。
例如，Squid 是一种流行的 HTTP 缓存，默认情况下它不会缓存任何具有查询字符串的 URL。此外，许多客户端甚至服务器和中介都以未定义的顺序生成和使用查询字符串参数；即“?a=3&b=5”可以任意改写为“?b=5&a=3”。但是，对于 HTTP 缓存，顺序很重要，即使两个页面具有相同的内容，它们也会被单独缓存。随着参数的增加，这个问题会成倍增加。
您应该通过两种相反但互补的技术来设计您的资源（及其表示形式）以利用缓存：
在您的情况下，第 1 步意味着将关联和部分组合到“用户”表示中，客户端没有任何选项来配置哪些和多少。这将允许您积极地缓存单个响应表示，而不会因所有查询字符串选项而导致您（和他们的）缓存因响应组合爆炸而过载。
第 2 步意味着将/users.json 分离为单独的“用户”实体，每个实体都有一个“关联”资源和一个“部件”资源。所以/users/{id} 和/users/{id}/associations 和/users/{id}/parts。然后，“/users”资源返回一个指向各个“/users/{id}”资源的超链接数组，每个“/users/{id}”表示都包含指向其关联和部分的超链接（该部分更具延展性- - 将关联和部分直接嵌入到用户资源中可能更适合您的应用程序。这将允许您积极缓存每个“需求”资源的响应，而无需缓存整个数据库。
然后您的用户会尖叫“但那是网络流量的 10 倍！”你平静地回应，“不，这是网络流量的 1/10，因为十分之九的请求资源已经在你的客户端（浏览器）缓存中（如果不是，它是 1/10）服务器的计算资源，因为它们位于服务器端缓存中，当它们也不存在时，我们避免在服务器上使用智能缓存进行标记）。”
当然，如果 /users 资源每天都有一百万新访问者访问，那么您的优化路径可能会有所不同。但根据您的示例 URI 方案，它似乎并非如此。
【讨论】：
【讨论】：
我会选择第一个。我不喜欢在 url 上看到 [] 符号，恕我直言，这让客户更难使用和理解。一些更改作为建议。
1) 由于关联似乎是一个数组，因此更改关联（复数，如果我是对的并且它是一个数组）
2) 您也可以尝试放置一个默认的 per_page 和一个可选的，甚至是聚合的，例如 per_page_parts_auditions，而不是同时使用 per_page_parts 和 per_page_auditions。如果您的 API 设计为公开的，我不会这样做，因为它更易于使用但更难理解，但正如您发布的那样，它是私有的......应该是避免复制的好方法。
【讨论】：