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

Posted 2023-03-31

【中文标题】Rails URL 的嵌套路由和参数（最佳实践）

【英文标题】：Nested Routes and Parameters for Rails URLs (Best Practice)

【发布时间】：2009-11-20 22:27:59

【问题描述】：

我对 RESTful url 以及不嵌套 url 背后的所有理论有相当的了解，但我仍然不太确定这在企业应用程序中的外观，比如 Amazon、*** 或 Google...

Google 有这样的网址：

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_i=507846&pf_rd_m=ATVPDKIKX0DER&pf_rd_r=1PK4ZKN4YWJJ9B86ANC9 http://www.amazon.com/Ruby-Programming-Language-David-Flanagan/dp/0596516177/ref=sr_1_1?ie=UTF8&s=books&qid=1258755625&sr=1-1

*** 是这样的：

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

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

有什么建议吗？

【参考方案1】：

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

如果一个资源总是在另一个资源中，嵌套它。没有错。比一个更深的地方有时会有点痛苦，因为你的路线会很长，而且会有点混乱。

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

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

【参考方案2】：

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

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

简而言之，将您可能从社区的某些部分听到的一些教条视为您可能想要更深入地思考您的设计的指南和信号。严格的 REST 只是另一种思考如何构建应用程序的方式。