5

在过去的两个月里，我一直在乱搞，到目前为止一切都进展顺利——但有一个领域我有点怀疑。

我不断听到关于 RESTful rails 资源的乐趣：即配置/路由中的“资源：foo”，以及控制器中的 7 个 RESTful 操作。

除了非常简单的事情（例如，通过运行“生成脚手架”完成 99% 的事情），我发现尝试将我的项目功能压缩到该方法中比只匹配配置/路由中的 url 并执行操作不太方便根据需要执行每个操作。

但是我一直觉得我错了，而且除了最极端的情况外，RESTful 资源都是可行的方法。

所以：

(a) 任何人都可以对此发表意见吗？

(b) 对于有经验的 Rails 人员，您在典型项目中的路线中有多少是 :resources，以及有多少是逐个操作编码的？干杯...

4

2 回答 2

5

资源很方便，但它们不是“一刀切”的功能。有些事情对这 7 种方法没有意义。

请记住，您可以：

  • 用 排除特定方法:except。
  • 仅包含带有:only.
  • 将您自己的方法添加到资源中。

所以它们并不像你想象的那么僵化。但是，如果在记住这 3 点之后，资源只是“感觉不对”，请跳过它！REST 从来没有打算取代常规路由，它只是试图抽象出最常见的用例。

如果您完全跳过 RESTful 资源，您将失去大量免费功能。明智地使用它，你会没事的。

于 2010-11-22T21:55:34.983 回答
0

通常，我在开始一个项目时会考虑 REST 架构。我以这种方式构建了我的基本功能，但是随着项目/网站的进展，我编写了越来越多不适合 RESTful 架构的视图。营销网站和并行功能就是很好的例子。

这是有关该方法的文章：

http://ablogaboutcode.com/2010/11/22/to-be-or-not-to-be-restful-ruby-on-rails-best-practices/

在开始之前，您可能想问自己以下一些问题：

  1. 这个控制器/视图是否主要处理像帖子、博客这样的对象/实体？
  2. 创建、更新、删除、编辑和新操作都将在 Web 上可用吗？

作为指导，如果您对这两个问题的回答为“是”，那么最好从 REST 开始，并期望您最终将架构用作您可能想要执行的其他操作和视图的构建块。否则，选择一个最能代表操作将显示或执行的 URL（/archives、/tour、/december-offer）并确保使用正确的 HTTP 协议（​​GET 用于显示，PUT 用于更新，DELETE 用于删除和 POST用于创建）。

于 2010-11-22T21:25:38.793 回答