与 ngResource 相比，使用 Restangular 有啥优势？

Posted 2023-03-04

【中文标题】与 ngResource 相比，使用 Restangular 有啥优势？

【英文标题】：What is the advantage of using Restangular over ngResource?与 ngResource 相比，使用 Restangular 有什么优势？

【发布时间】：2013-05-09 09:46:06

【问题描述】：

ngResource 已经似乎真的很简单用...实现一些东西

使用Restangular 与ngResource 相比有哪些优点/缺点？

1.1.3 $resource 将返回承诺，并且可以使用 latest PR commit 实现。将来是否会向$resource 提供支持以支持 Restangular 支持的其他动词？如果发生这种情况，Restangular 似乎会消失并变得无关紧要。

【问题讨论】：

为什么要关闭？这是一个有效的问题，应该有明确的答案。尤其是在游戏的早期，当您试图决定使用什么来进行服务调用时。当这个人放弃对 Restangular 的支持时，三个月后会发生什么，因为谷歌的 ngResource 赶上了它所缺少的所有功能。然后，如果对 angularjs 进行了主要的 $http 发布更改 --- 您将无法升级，因为 Restanualr 的服务调用将期待“其他东西”，并且您最终会破坏您“决定使用”的这个框架.

在这里查看github.com/mgonto/restangular/blob/master/…

@DanKanze：中级 SO 用户对此类问题非常满意。这真的很令人沮丧，因为你肯定不会问“哪个更好”......我唯一的建议是在未来小心地提出问题，以免诱使“主观盖世太保”全力以赴。

【参考方案1】：

我是 Restangular 的创造者。

我在自述文件中创建了一个部分，其中包含与 $resource 的差异。你可以在这里查看它们https://github.com/mgonto/restangular/blob/master/README.md#differences-with-resource

总之，总而言之，除了附加功能和基于 Promise 的方法之外，Restangular 还可以处理您的所有 URL，因此您不必了解它们。

假设你有这样的汽车：/users/123/cars/456

在 $resource 中，您必须手动构建该 URL，并且您还必须为此手动构建 $resource 对象。 Restangular 通过“记住” URL 来帮助您。

所以如果你在某个地方这样做

Restangular.one("users", 123).get().then(function(user) 
  $scope.user = user;
);

// Some other code

//Automatically does the request to /users/123/cars as it remembers in which object you're asking it.
$scope.user.getList('cars')

希望这会有所帮助！

【讨论】：

+1 表示参与其中。谁能更好地解释自己建造它的人哈哈！

.one('users', 123) 如何比'/users/123' 更多或更少地“了解”您的 URL？ （只是扮演魔鬼的拥护者）似乎'/foo/123/bar/123' 比.one('foo', 123).one('bar', 123) 容易得多。

这个想法是，在某些时候，您只知道实体名称和 id。所以你首先要做一些谎言var user = Restangular.one('users', 123).getList()。稍后在代码或其他一些控制器中，您执行user.getList('buildings')。在这里，您只知道下一个类型是建筑物，但它会查询/users/123/buildings/，因此您不必一直都知道完整的 URL

好但片面。关于最近对$resource 的增强，在这个线程中已经提出了 Restangular 可能的“无关性”——我并不暗示它会变得无关紧要，只是已经提到过。我们应该注意的任何事实缺点或陷阱？

自述文件中的很多内容已经过时并使用了更新的 ngresource 版本？ （即/使用promise，通过transformResponse装饰响应对象）

【参考方案2】：

我发现 Restangular 的 RequestInterceptor 在发出请求之前从对象中删除一些字段非常方便。我目前正在使用的大多数 REST Web 服务不期望 PUT 请求中的对象数据中的 id，例如，只是在 url 中。通常，他们不会期望 PUT 无法更新的额外数据字段（例如 id 或通过设置标题等生成的 slug）。我发现这对于 Restangular 来说很简单，虽然我还没有弄清楚如何以一种干净的方式使用 $resource 来做到这一点，但我相信它可能以某种方式实现。

显然，也可以更改网络服务以忽略那些额外的字段，但这并不总是可能的。

【参考方案3】：

ngResource 在最新的稳定版本（当前为 1.0.6）中不返回承诺。此外，看起来 Restangular 暴露了比 ngResource 更多的动词（它暴露了 PUT、OPTIONS、PATCH 等）。

如果你不需要额外的动词并且在 AngularJS 的不稳定分支上（其中包括对 ngResource 的承诺），我认为没有任何主要原因使用 Restangular 而不是 ngResource。

使用任何你觉得舒服的东西。

【讨论】：

1.1.3 $resource 将返回承诺，并且可以使用最新的 PR 提交来实现。 ***.com/questions/16429832/… 将来是否会向$resource 提供支持以支持其他动词？如果发生这种情况，Restangular 似乎会消失并变得无关紧要。

@DanKanze 我不确定未来是否支持其他动词。对于大多数用例，额外的动词不是必需的，所以我不希望它很快就会内置，但这并不意味着它不会发生。

@DanKanze - 我怀疑它会变得无关紧要。 Restangular 为嵌套资源提供了更好的支持，这是一些开发人员的要求。 Ng-resource 不太支持的东西。此外，ng-resource 也不遵循 RESTful 约定，这是我在博客中谈到的。

@Oddman 关于嵌套资源伙伴的好点，对 Rails 后端特别有用。

【参考方案4】：

作为对上述答案的跟进，对于像我这样对这些想法感兴趣的新读者：

“如果发生这种情况，Restangular 似乎会消失并变得无关紧要。”

“当这家伙放弃支持时，三个月后会发生什么 Restangular，因为 Google 的 ngResource 赶上了所有功能 它不见了。”

[2 年前问过]

在我看来，唯一保证开源库生存的保证是围绕它建立的社区。一个最好的例子是 mariaDB 和 WebScaleSQL，它们都是作为关系数据库管理系统 mysql 的一个不断增长的分支而诞生的。

在撰写本文时，Restangular having 6699 stars and 727 forks 现在正在向 Restangular 2.0 发展，旨在支持 angularJs 2.0 和 ES6。

讨论：https://github.com/mgonto/restangular/issues/890. 第一次回购预览： https://github.com/mgonto/restangular/tree/2.0-wip ng-europe 会议由 mgonto 介绍： https://youtu.be/fWar75R1NGo

【参考方案5】：

对于您希望在最少支持下永久运行的快速简单网站，我会使用内置的 angular http HttpClient，无论我在做什么我都喜欢并且我喜欢的项目'我喜欢并尝试使用所有很酷的技术，然后我将使用 Ngx-Restangular

您还应该知道，ngx-restangular 仅顾名思义与 RESTful 服务一起使用。因此，对于提供 SOAP 的服务，您将无法使用 Ngx-Restangular

https://ngx-restangular.com/

话虽如此，我大部分时间都会使用 ngx-restangular，因为我总是尝试从事我觉得很酷的项目并尝试实施我认为最好的项目。

祝你好运！