自 2007 年以来，我与 ActiveResource 进行了广泛的合作，并在 Rails 从 v1.2 升级到 v4.0 期间使用 ARes 构建和维护了一个多服务分布式架构。在我看来，作为当前形式的公共图书馆，ARes从根本上是有缺陷的，但它包含许多可以在单个系统中使用的好想法。我做了一个关于我们在公司从 ARes 迁移出来的演讲。
人们在实践中不喜欢 ARes 的一个重要原因是他们不同意的维护不善或实施细节。诸如处理您同事提到的错误消息之类的事情属于此类别。此外，随着时间的推移，您会发现由于不明智的一次性改进或错误修复，甚至是 Rails 内部变化的渗透（例如，去年YAML 灾难来袭时，我们的 ARes 遭遇了灾难性的崩溃）。系统）。但是所有这些事情都可以通过更好的维护和更好的视野来改进，将这些问题与基本问题分开很重要。
我开始相信，以及 Yehuda 在上面的评论中提到的，ARes 失败了，因为 REST API 没有一般的具体语义。即使利用最好的 Rails 约定，HTTP API 语义充其量也是脆弱的。
与 ActiveRecord 所做的对比，它生成 SQL：一种用于选择数据行的定义良好的声明性语言。SQL 基于关系模型，它为我们提供了基于不同子句的查询含义的数学定义。这种数学基础允许像 Arel 这样的东西在 ruby 中创建可组合的 SQL DSL。在 SQL 数据库中，可以执行任何语法正确的查询（即使它太慢而不实用），因为引擎被设计为正式解析和映射 SQL 语句以可证明正确的实现来操作和获取基础数据。因此，当您在此基础上构建像 ActiveRecord 这样的 ORM 时，您在底层系统中有非常强大的保证。如果您生成有效的 SQL 引擎保证它会工作，如果您生成无效的 SQL，引擎会返回一个错误。即使 SQL 标准化，值得注意的是每个数据库都有一个单独的 ActiveRecord 适配器，以确保正确性和正确映射到 ActiveRecord 功能。它们中的每一个都使用底层驱动程序来保证对正在运行的数据库的正确有线协议实现。所有这些代码背后都有相当多的规范和维护，所有这些都使当今的 ActiveRecord 具有良好的优雅性和可靠性。
现在考虑一个 HTTP API 及其支持？它可以是任何数据库技术，或者根本就没有！它很可能是内部编写的，并且仅提供业务功能所必需的内容。与在其模式中携带有关通用查询操作的所有必要信息的数据库不同，HTTP API 与任何底层存储机制或业务逻辑完全解耦。即使 API 提供了如何使用查询参数的标准，也没有关于哪些过滤器或排序选项可用的自文档定义。哎呀，即使检查参数的有效性也不能保证，因为 API 通常不会吞下或忽略无效的参数。
综上所述，ARes 非常方便，但它是建立在流沙之上的。它使用的想法和惯例很方便，但它们缺乏凝聚力的愿景和稳定性，无法可靠。就我个人而言，我认为使用自己的约定和可靠的规范来滚动你的 ARes 看起来很相似，然后你可以将它们应用于你的服务实现并不是不合理的。
在建立一个像 ARes 之类的东西可能有意义的基础方面，Yehuda Katz 和 Steve Klabnik 的优秀JSON:API规范是一个很棒的社区项目，它将为这样一个基础提供一个非常重要的构建块，但值得注意的是就语义保证和可派生功能而言，它仍然远不及特定的数据库驱动程序。我怀疑一个真正优秀的类 ARes 库来利用 JSON-API 看起来与它今天所做的有很大不同，以更好地包含与 RDBMS 相比，即席 API 中隐含的灰色区域。
编辑：经过两年激烈的辩论和来自不同社区的反馈，JSON:API刚刚达到 1.0。我估计在这个规范中投入的工作量比 ActiveResource 所达到的要多几个数量级。尽管它与 ActiveResource 的抽象级别不同，但 JSON:API 追求类似的目标，即提供标准语义，以便 API 更易于生产和使用。查看一些实现可以很好地了解 JSON:API 可以提供多少杠杆作用。