ngResource
已经看起来非常简单来实现......
使用Restangular而不是ngResource有哪些优点/缺点?
1.1.3 $resource
将返回承诺,并且可以使用latest PR commit来表达。是否会向$resource
提供未来支持以支持Restangular所做的其他动词?如果发生这种情况,Restangular似乎会消失并变得不可靠。
答案 0 :(得分:232)
我是Restangular的创造者。
我在README上创建了一个与$ resource有区别的部分。你可以在这里查看https://github.com/mgonto/restangular/blob/master/README.md#differences-with-resource
无论如何,总而言之,除了附加功能和基于承诺的方法之外,我们的想法是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 :(得分:8)
我发现Restangular的RequestInterceptor非常方便在发出请求之前从对象中删除一些字段。我目前正在使用的大多数REST Web服务不希望PUT请求中的对象数据中的id,例如,仅在url中。通常,他们不期望PUT无法更新的额外数据字段(如id,或通过设置标题等生成的slug)。我发现这对Restangular来说很简单,而我还没有弄清楚如何以干净的方式使用$ resource,但我确信它可能以某种方式。
显然,人们也可以将网络服务改为忽略那些额外的字段,但这并不总是可行。
答案 2 :(得分:3)
ngResource不会在最新的稳定版本(目前为1.0.6)中返回promises。另外,它看起来像Restangular暴露了比ngResource更多的动词(它暴露了PUT,OPTIONS,PATCH等)。
如果你不需要额外的动词并且在AngularJS的不稳定分支上(包括ngResource的promises),我认为没有任何主要理由使用Restangular而不是ngResource。
使用你觉得舒服的任何东西。
答案 3 :(得分:1)
作为以上答案的后续内容以及像我这样的新读者,对这些想法感兴趣:
"如果发生这种情况,Restangular似乎会消失并变得不重要。"
"当这个家伙放弃支持时,三个月内会发生什么 Restangular因为Google的ngResource占据了所有功能 它不见了。"
在我看来,仅保证开源库的存在是围绕它构建的社区。一个最好的例子是 mariaDB 和 WebScaleSQL ,它们都是作为伟大的关系数据库管理系统MySQL的增长分支而诞生的。
在写作时,Restangular having 6699 stars and 727 forks
现在向前移动到Restangular 2.0,这意味着支持angularJs 2.0和ES6。
答案 4 :(得分:0)
对于希望在最小的支持下永远运行的快速简单网站,无论我从事的项目是什么,我都会使用内置的有角度的http HttpClient 我会享受并尝试使用所有很酷的技术,然后使用 Ngx-Restangular
此外,您应该知道ngx-restangular仅在名称提示下与RESTful服务一起使用。因此,对于提供SOAP的服务,您将无法使用 Ngx-Restangular
话虽这么说,我将大部分时间都使用ngx-restangular ,因为我总是尝试从事我认为很酷的项目并尝试实现我认为最好的项目。
祝你好运!