来自不同团队的几位开发人员独立告诉我，ActiveResource是一个有缺陷的想法。我听到的最常见的批评是将它设计为具有类似ActiveRecord的界面是错误的。我也听到有关错误处理方式或吞噬方式的投诉。一位开发人员实际创建了自己的gem，以提供与ActiveResource相同的功能（基于RESTful资源的模型框架）。
我是ActiveResource的新手，但是当我查看代码并进行实验并了解它是如何工作的时候，我很难看出阻力来自哪里。它似乎基于干净，坚实的概念。我甚至听说它太重了！但在我的检查中，我发现它很轻快。
因此，关于ActiveResource的所有争议，我转向网络寻求答案。当然，必须有一堆博客文章，说明为什么ActiveResource应该被用来支持X.毕竟，我确实可以找到关于DataMapper是否优于ActiveRecord的帖子。所以我搜索过，我搜索过......没什么。没有一件事。我无法在互联网上找到任何批评ActiveResource的页面（除了对REST的全面批评）。我甚至找不到建议的替代方案。它得到了Rails核心团队的支持，似乎是社区中事实上的标准。
底线：
ActiveResource存在争议吗？如果是这样，辩论的本质是什么？还有其他选择吗？
答案 0 :(得分：9)
自2007年以来，我一直在广泛地使用ActiveResource，并且在Rails从v1.2升级到v4.0期间，使用ARes构建并维护了一个多服务分布式架构。在我看来，ARes 在其当前形式中作为公共图书馆存在根本缺陷，但它包含许多可以在个别系统中使用的好主意。我给了a talk关于我们在公司做的事情，以便远离ARes。
人们在实践中不喜欢ARes的一个重要原因是他们不同意维护或实施细节。处理您的同事的错误消息属于此类别。此外，随着时间的推移，您会发现由于不明智的一次性改进或错误修复而导致事情突然发生，甚至Rails内部更改渗透（例如，去年YAML-pocalypse遭遇灾难时，我们遭受了灾难性的打击我们的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提供了如何使用查询参数的标准，也没有可用的过滤器或排序选项的自我文档定义。哎呀，即使检查params的有效性也不能保证，因为API通常不会吞没或忽略无效的参数。
所有这一切，ARes非常方便，但它建立在流沙之上。它使用的想法和惯例很方便，但它们缺乏凝聚力和可靠性的稳定性。就个人而言，我认为使用自己的约定和固定规范来推动您的ARes看起来相似，然后您可以将其应用于您的服务实现并非不合理。
在建立基础之上，像ARes这样的东西是有意义的，Yehuda Katz和Steve Klabnik的优秀JSON:API规范是一个伟大的社区项目，将提供一个非常重要的构建块这样的基础，但值得注意的是，在语义保证和可派生功能方面，它仍然没有出现在特定数据库驱动程序附近的任何地方。我怀疑，与RDBMS相比，利用JSON-API的非常好的类似ARes的库看起来与现在有很大不同，以更好地接受adhoc API中隐含的灰色区域。
编辑：JSON:API经过两年的激烈辩论和来自不同社区的反馈，刚刚达到1.0。我估计在这个规范中投入的工作量比ActiveResource实现的工作量高出几个数量级。尽管它与ActiveResource具有不同的抽象级别，但JSON：API追求的目标是提供标准语义，以便API更易于生成和使用。查看一些implementations可以很好地了解JSON：API可以提供多少杠杆。
答案 1 :(得分：2)
已经从Rails 4.0中的Rails中提取了ActiveResource。
很多人只使用RestClient或HTTParty或其他库。这些库通常被认为更简单，更容易使用。