ruby-on-rails - Rails URL 的嵌套路由和参数（最佳实践）

Question

我对 RESTful url 以及不嵌套 url 背后的所有理论有一个不错的理解，但我仍然不太确定这在企业应用程序中的外观，比如亚马逊、StackOverflow 或谷歌......

谷歌有这样的网址：

• http://code.google.com/apis/ajax/
• http://code.google.com/apis/maps/documentation/staticmaps/
• https://www.google.com/calendar/render?tab=mc

亚马逊是这样的：

• http://www.amazon.com/books-used-books-textbooks/b/ref=sa_menu_bo0?ie=UTF8&node=283155&pf_rd_p=328655101&pf_rd_s=left-nav-1&pf_rd_t=101&pf_rd_t=101&pf_rd_i=507846&pf_rd_m=ATVPDKIKX049&pf_WJ_KN46ATVPDKIKX0494PKZNCKN4
• http://www.amazon.com/Ruby-Programming-Language-David-Flanagan/dp/0596516177/ref=sr_1_1?ie=UTF8&s=books&qid=1258755625&sr=1-1

StackOverflow 是这样的：

• https://stackoverflow.com/users/169992/viatropos
• https://stackoverflow.com/questions/tagged/html
• https://stackoverflow.com/questions/tagged?tagnames=html&sort=newest&pagesize=15

所以我的问题是，为这样的系统创建 url 的最佳实践是什么？你什么时候开始在 url 中存储参数，什么时候不呢？这些大公司似乎没有遵守 ruby​​ 社区中如此激烈争论的规则（例如，你几乎不应该嵌套 URL），所以我想知道你如何在更大规模的项目中实现自己的 url，因为它似乎不嵌套 url 的想法在任何比博客更大的东西上都失效了。

有小费吗？

Answer 1

不要太拘泥于 Ruby 社区的“规则”。这个想法是在嵌套 URL 时不应该过分，但是当它们合适时，它们被内置到 Rails 框架中是有原因的：使用它们。

如果一个资源总是属于另一个资源，则嵌套它。没有错。比一个人更深入有时会有点痛苦，因为您的路线路径会很长并且可能会有点混乱。

另外，不要将嵌套与命名空间混淆。仅仅因为您看到 example.com/admin/products/1234/edit 并不意味着发生了任何嵌套。当它们实际上不在代码级别时，路由可以使事物看起来是嵌套的。

我个人是嵌套的忠实拥护者，并且在我的应用程序中经常使用它（只有一层——偶尔是两层）。此外，添加使用单词而不仅仅是 ID 的永久链接样式 URL 在视觉上更具吸引力，并且它们可以帮助 SEO，无论它们是否嵌套。

Answer 2

我相信支持或反对 REST 和/或在路由中嵌套的论点与您希望如何公开 API 有很大关系。如果您不想公开为您的应用程序公开 API，那么有一种说法是，严格遵守 RESTful 设计是浪费时间，特别是如果您不同意 REST 背后的推理。你的选择。

我发现考虑客户端（除了浏览器）如何访问您的应用程序中的信息有助于设计过程。从 API 角度考虑应用程序设计的最大优势之一是您倾向于消除不必要的复杂性。对我来说，这是您在 Rails 社区中听到的关于嵌套路由的警告的根源。我认为这表明事情变得有点复杂，可能是时候退后一步重新考虑这种方法了。“比博客还大”的系统不必天生就复杂。有些部分可能是，但当您从不同的角度处理设计时，您也可能会感到惊讶。

In short, consider some of the dogma you might hear from certain parts of the community as guides and signals that you may want to think more deeply about your design. Strict REST is simply another way to think about how you are structuring your application.