API的URL设计
我正在为我们的后端工作私人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}”表示包含指向其关联和部分的超链接（该部分更具延展性 – -it可能更适合您的应用程序，直接将关联和部分嵌入到用户资源中。这将允许您积极地缓存每个“按需”资源的响应，而无需缓存整个数据库。
然后你的用户会尖叫“但这是网络流量的10倍！” 你冷静地回答，“不，这是网络流量的十分之一，因为所需资源中的9个已经位于客户端（浏览器）缓存中（当它们不在时，它是1/10服务器的计算资源，因为它们位于服务器端缓存中，当它们不存在时，我们避免在服务器上加盖智能缓存。“
当然，如果/users资源是每天有大量新访问者访问的内容，那么您的优化路径可能会有所不同。 但它似乎不是基于您的示例URI方案。
restful-url标签下有很多有用的post。
一些有用的post：
REST API URL必须如下所示吗？
在REST调用中使用URI作为参数值的最佳实践。
如何创建没有动词的REST URL？
我会选择第一个。 我不喜欢在url上看到[]符号，恕我直言，它使客户更难以使用和理解。 作为建议的一些变化。
1）由于关联似乎是一个数组，更改为关联（复数，如果我是正确的，它是一个数组）
2）您还可以尝试设置默认的per_page和可选的per_page，甚至是聚合，例如per_page_parts_auditions，而不是同时使用per_page_parts和per_page_auditions。 如果您的API设计为公开的，我不会这样做，因为它更容易使用但更难理解，但是当您发布它是私有的时…应该是避免复制的好方法。