我正在为我们的后端开发一个私有 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 方案吗？
谢谢 ！
我的回答：/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}”表示都包含指向其关联和部分的超链接（该部分更具延展性- -将关联和部分直接嵌入到用户资源中可能更适合您的应用程序。这将允许您积极缓存每个“需求”资源的响应，而无需缓存整个数据库。
Then your users will scream "but that's 10 times the network traffic!" To which you calmly respond, "no, that's 1/10th the network traffic, because 9 times out of 10 the requested resources are already sitting in your client-side (browser) cache (and when they're not, it's 1/10th the server's computational resources since they're sitting in a server-side cache, and when they're not there either, we avoid stampeding with a smart cache on the server)."
Of course, if the /users resource is something a million new visitors hit every day, then your optimization path might be different. But it doesn't seem so based on your example URI schemes.
在restful-url标签下有很多有用的帖子。
一些有用的帖子：
我会去第一个。我不喜欢在 url 上看到 [] 符号，恕我直言，这让客户更难使用和理解。一些更改作为建议。
1）由于关联似乎是一个数组，因此更改关联（复数，如果我是对的并且它是一个数组）
2) 你也可以尝试放置一个默认的 per_page 和一个可选的，甚至是聚合的，比如 per_page_parts_auditions，而不是同时使用 per_page_parts 和 per_page_auditions。如果您的 API 设计为公开的，我不会这样做，因为它更易于使用但更难理解，但正如您发布的那样，它是私有的 .. 应该是避免复制的好方法。