首选 Rails 3 RESTful 设计？

Posted 2023-02-16

【中文标题】首选 Rails 3 RESTful 设计？

【英文标题】：Rails 3 RESTful design preferred?

【发布时间】：2011-04-23 22:25:07

【问题描述】：

我是 Rails 3 的新手，我正在尝试了解以 RESTful 方式设计应用程序的优势。我不需要 API/Web 服务。不需要 XML 或 JSON。

我正在构建的应用程序根本不使用 CRUD。它是一款通过套接字连接收集交易数据并以多种不同方式向用户显示的应用程序。

我想以不同的方式可视化交易，例如：

最近的 最高产量 各州贸易 最活跃的交易 百万美元交易 一般义务债券的交易 等等……

在“Rails 方式”中，我似乎会有一个非常重载的索引操作。或者我可以违反惯例，只在交易控制器中创建方法，例如 most_recent、highest_yielding、most_active 等。但这似乎违背了在 Rails 3 中设计应用程序的整个理念。

Rails 中的 RESTful 方法背后的想法似乎是基于 CRUD 的，并且在不涉及 CRUD 的情况下就不足了。除了遵循约定之外，将您的应用程序设计为“RESTful”真的有优势吗？我并没有真正看到这里的优势。

另外，如果我确实需要一个 API，我想设计一个考虑到 API 的 API 会好得多。我的 API 不会是我的网站的直接一对一匹配，它是为人类消费和机器而构建的。

我将不胜感激任何对此的见解。也许我在这里遗漏了什么？

【问题讨论】：

涉及到 CRUD - 您列出的所有用于“可视化”交易的方式都包含在 CRUD 的“R”部分，代表“读取”。

我想问这个问题的更好方法是：处理“阅读”繁重的资源的最佳方法是什么。它们是否都指向具有许多 IF 语句的单个索引操作？这似乎很乱。这就是我的意思。

【参考方案1】：

当涉及到资源时，实际上会涉及到 CRUD。而且由于几乎每个应用程序都有资源 CRUD 可以参与并且通常（如果你问我）是最好的方法。

这个想法是资源具有某些动作。您查看资源，编辑它，删除它等等。像 most_recent（或这个范围）这样的方法应该在模型而不是控制器中使用。然后，如果您需要使用该集合，您只需调用类似：

@recent_posts = Post.most_recent

在您的控制器中。您的控制器不应该有太多代码，实际上根本没有业务逻辑。

RESTful 非常好，因为它自然地处理资源。控制器实际上应该处理资源。如果您认为可以编辑或创建某些内容，那么它应该由控制器处理。

一般来说，我强烈建议您深入了解一下，您一定会看到自己的优势。

【参考方案2】：

我知道该怎么做。代码没有测试，我只是写了没有运行。

控制器：

# trades_controller.rb
def index
  # all scopes defined in model will be allowed here
  # not good idea if you don't want it
  if Trade.scopes.has_key?(params[:scope].to_sym)
    @trades = Trade.send(:params[:scope]) 
  else
    # render error or what you want
  end
end

型号

# trade.rb
  scope :most_recent, order(:created_at)
  # more scopes

查看

# index.html.erb
link_to 'Most recent', trades_path(:scope => 'most_recent')

【讨论】：

这是有道理的。我想我也可以根据范围决定渲染什么视图。

【参考方案3】：

您的设计应始终首先考虑应用程序的要求，其次才是框架的理念。

如果该理念不符合您的要求或您认为开发应用程序的最佳方式，则要么忽略它，要么如果框架让您难以按照您认为的那样构建（这是在 Rails 中不是这种情况，请切换到另一个框架。

所有这些都与 REST 没有太大关系。有关为什么 REST 被认为是一个好主意的更多信息（对于某些而非全部），请参阅以下 SO 问答：Why would one use REST instead of Web services 和 What exactly is RESTful programming。