我正在制作我的第一个真正的Rails应用程序，并且正在学习REST架构以及它如何适应Rails应用程序。我的控制器似乎并没有真正地映射到单个资源，因此我很难实现严格的REST。例如，我有一个“目录”，“结帐”和“管理”控制器，而不是“产品”，“类别”，“订单”和“用户”控制器，尽管这些是这些控制器中使用的主要资源。每个控制器不仅仅执行资源上的REST操作，而且所有控制器都从多个模型中提取并为多个视图提供服务。
我是否错过了一个设计/架构实践，可以让REST更好地工作？可能是命名空间控制器，仅在顶级控制器中使用非REST操作，在子控制器中使用REST操作？好像我会在那里遇到一些干扰......
答案 0 :(得分：2)
如果这是您想要构建应用程序的方式，请忘记REST并只映射您需要的路线。如果你真的不想管理资源，为什么要这么麻烦？
答案 1 :(得分：1)
REST非常适合资源。将结账程序映射为一个宁静的资源并且不值得付出努力是非常痛苦的，就个人而言，我只是在我的结账控制器中有4/5的操作，而这似乎可以完成这项工作。
如果您需要助手，可以映射命名路线
checkout_delivery_path
map.checkout_delivery '/checkout/delivery', :controller => "checkout", :action => "delivery"
答案 2 :(得分：1)
如果您查看HTTP规范here 你会发现POST可以用来做的一件事是：
Providing a block of data, such as the result of submitting a form, to a data-handling process;
因此，您可以创建一个“数据处理过程”的控制器，并在不违反任何REST约束的情况下对其执行POST。如果使用名词命名资源，则可以使URL感觉更加RESTful，但实际上并非没有必要。 e.g。
POST /MyStore/CheckoutGirl
至于你的目录，我不明白为什么它不容易映射。 GET / MyStore / Catalog / Item / 2324 GET / MyStore / Catalog / SaleItems
管理员通常会映射到用户，角色等。那里没有什么新东西。
答案 3 :(得分：1)
不要试图将REST的每个方面都用到每个应用程序中。 REST是一种体系结构，并不适用于所有目的。如果你需要的是一些RPC动作，那么使用其他形式的RPC，而不是REST的以资源为中心的原则。
此外，URL命名方案与您的应用程序是否为REST是完全无关的。这不是REST的意义所在。他们很高兴，但只是为你的应用做了有意义的事。