我对RESTful网址以及不嵌套网址背后的所有理论都有一个很好的理解，但我仍然不太确定它在企业应用程序中的外观，如亚马逊，StackOverflow或Google等......
Google的网址是这样的：
和StackOverflow这样：
所以我的问题是，在为这样的系统创建网址方面，最佳做法是什么？什么时候开始在网址中存储参数，什么时候不是？这些大公司似乎没有遵循ruby社区中如此热烈争论的规则（例如，你几乎不应该嵌套URL），所以我想知道如何在大型项目中实现自己的URL，因为它似乎没有嵌套网址的想法会破坏任何比博客更大的内容。
任何提示？
答案 0 :(得分：6)
不要被Ruby社区中的“规则”所困扰。我们的想法是，在嵌套URL时不应该过分，但是当它们合适时，它们会被构建到Rails框架中，原因是：使用它们。
如果资源始终属于另一个资源，请将其嵌套。没有错。比一个更深的有时可能会有点痛苦，因为你的路线路径很长，会让人感到有些困惑。
另外，不要将嵌套与命名空间混淆。仅仅因为你看到example.com/admin/products/1234/edit并不意味着发生了任何嵌套。当路由实际上不在代码级别时，路由可以使事物看起来是嵌套的。
我个人非常喜欢嵌套，并且在我的应用程序中经常使用它（只有一个级别 - 有时是两个级别）。此外，添加使用单词而不仅仅是ID的固定链接样式URL更具视觉吸引力，它们可以帮助SEO，无论它们是否嵌套。
答案 1 :(得分：1)
我认为支持或反对REST和/或在您的路由中嵌套的论据与您希望公开API的方式有很大关系。如果您不想公开为您的应用程序公开API，那么有一种观点认为严格遵守RESTful设计是浪费时间，特别是如果您不同意REST背后的原因。你的选择。
我发现考虑客户端（浏览器除外）如何从您的app访问信息有助于设计过程。从API角度考虑应用程序设计的最大优势之一是您倾向于消除不必要的复杂性。对我而言，这是您在围绕嵌套路由的Rails社区中听到的警告的根源。我会把它作为一个迹象表明事情变得有点复杂，可能是时候退后一步重新思考这个方法了。 “大于博客”的系统本身并不复杂。有些部分可能是，但是当你从不同的角度来看设计时，你也会感到惊讶。
简而言之，请考虑一些您可能从社区某些部分听到的教条作为指导和信号，表明您可能想要更深入地思考您的设计。严格的REST只是考虑如何构建应用程序的另一种方式。
答案 2 :(得分：-8)
首先要意识到的是，如果你看一下示例应用程序和示例代码，Rails只适用于构建博客和购物车。
接下来，您将会发现提倡RESTful URL和没有嵌套的路由的人可能只是在构建博客和购物车。
最终会有启发，你会接受RESTful URL和非嵌套路线是一堆废话，然后你可以继续实际构建你的应用程序并完成工作。