ngResourceよりもRestangularを使用する利点は何ですか?


133

ngResourceものを実装することはすでに本当に簡単思えます ...

ngResourceよりもRestangularを使用する利点/欠点は何ですか?

1.1.3 $resourceは約束を返し、最新のPRコミットを使用して実装できます。$resourceRestangularが行う追加の動詞をサポートするために、将来のサポートは提供されますか?そして、それが起こった場合、Restangularは消えて無関心になるようです。


41
なぜ閉じる?これは、明確な回答が必要な有効な質問です。特にゲームの早い段階で、サービスコールに何を使用するかを決定しようとしているとき。GoogleのngResourceが不足していたすべての機能に追いついたため、この人がRestangularのサポートを中止した3か月後に何が起こりますか。次に、$httpangularjsにメジャーリリースの変更が加えられた場合--- Restangualrのサービスコールは「何か他のもの」を想定しているため、アップグレードできません。このフレームワークは、「使用することを決定した」ものではありません。
Dan Kanze 2013年

1
ここではそれらをチェックアウトgithub.com/mgonto/restangular/blob/master/...
mgonto

@DanKanze:中間レベルのSOユーザーは、このような質問に非常に満足しています。「どちらがいいか」を尋ねているのではないので、本当にイライラします...私の唯一の提案は、「主観的なゲシュタポ」が全力であなたに降りるように誘惑しないように、将来の質問を注意深くフレーズすることです。
rinogo 2016年

回答:


232

私はRestangularの作成者です。

READMEに$ resourceとの違いを説明したセクションを作成しました。こちらでチェックできますhttps://github.com/mgonto/restangular/blob/master/README.md#differences-with-resource

とにかく、要約すると、追加機能とプロミスベースのアプローチに加えて、RestangularはすべてのURLを処理できるため、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')

お役に立てれば!


45
これにジャンプするための+1。誰がそれを説明した方がいいですか?
Dan Kanze 2013年

27
どのようにされ .one('users', 123)、それ以上か未満あなたのURLについては、「知っていますか」'/users/123'?(ちょうど悪魔の支持者を演じる)それはちょうど'/foo/123/bar/123'よりもはるかに簡単なようです.one('foo', 123).one('bar', 123)
Ben Lesh 2013

5
アイデアは、ある時点で、エンティティ名とIDを知っているということです。だからあなたはまず嘘をつくvar user = Restangular.one('users', 123).getList()。後のコードまたは他のコントローラーでは、そうしますuser.getList('buildings')。ここでは、次のタイプである建物だけを知っていますが、クエリを実行/users/123/buildings/しているため、常に完全なURLを知っている必要はありません
mgonto

3
良いですが、一方的なものです。Restangularの「関連性」の可能性は、最近の機能強化に関してこのスレッドで提案されています$resource-言及されただけで、それが何らかの意味で無関係になることを意味しません。知っておくべき事実上の欠点や落とし穴はありますか?
youri 2013

3
そのREADMEには、ngresourceの最新バージョンで古くなっているものが多くありませんか?(つまり、
promiseの

8

RestangularのRequestInterceptorは、リクエストを行う前にオブジェクトからいくつかのフィールドを削除するのに非常に便利です。私が現在使用しているほとんどのREST Webサービスは、PUTリクエストのオブジェクトデータのIDを期待していません。たとえば、URLだけです。一般に、PUTで​​更新できない余分なデータフィールド(ID、またはタイトルの設定などによって生成されるスラッグなど)を期待していません。$ resourceを使用してクリーンな方法でそれを行う方法を理解していませんが、これはRestangularで簡単であることがわかりましたが、どういうわけかそれは可能だと確信しています。

もちろん、これらの余分なフィールドを無視するようにWebサービスを変更することもできますが、それが常に可能であるとは限りません。


3

ngResourceは最新の安定版リリース(現在は1.0.6)でpromiseを返しません。さらに、RestangularはngResourceよりも多くの動詞を公開しているように見えます(PUT、OPTIONS、PATCHなどを公開しています)。

追加の動詞が不要で、AngularJSの不安定なブランチ(ngResourceのpromiseを含む)にいる場合、ngResourceよりもRestangularを使用する主な理由はわかりません。

あなたが快適に感じるものは何でも使用してください。


2
1.1.3 $resourceは約束を返し、最新のPRコミットを使用して実装できます。stackoverflow.com/questions/16429832/…$resource追加の動詞をサポートするために将来のサポートが提供されますか?そして、それが起こった場合、Restangularは消えて無関心になるようです。
Dan Kanze 2013年

@DanKanze追加の動詞の将来のサポートについてはわかりません。ほとんどのユースケースでは、追加の動詞は必要ないので、すぐに組み込まれるとは思いませんが、それが起こらないという意味ではありません。
rtcherry 2013年

2
@DanKanze-それが無関係になるとは思えません。Restangularは、一部の開発者の要件であるネストされたリソースのサポートを大幅に改善しています。Ng-resourceが特にサポートしていないもの。さらに、ng-resourceはRESTful規則にも従いません。これは、ブログで話しました。
オッドマン2013

ネストされたリソースメイトに関する@Oddmanの良い点、特にRailsバックエンドに役立ちます。
ardochhigh 2014年

1

上記の回答のフォローアップとして、そして私のような、それらの考えに興味のある新しい読者のために:

「そしてそれが起こると、Restangularは消えて無関心になるようです。」

「GoogleのngResourceが不足していたすべての機能に追いついたため、この人がRestangularのサポートを中止した3か月後に何が起こるでしょうか。」

  • [ 2年前に尋ねた ]

私の意見では、オープンソースライブラリの存続に対する唯一の保証は、それを中心に構築されたコミュニティです。最良の例はmariaDBWebScaleSQLで、どちらも優れたリレーショナルデータベース管理システムMySQLへの分岐点として生まれました。

この執筆時点で、Restangular having 6699 stars and 727 forksは現在、angularJs 2.0およびES6をサポートすることを目的としたRestangular 2.0に移行しています。


0

最小限のサポートで永遠に実行したい簡単なウェブサイトのために、私が好きなプロジェクトで作業しているときは誰でも組み込みの角度のあるhttp HttpClientを使用し、すべてのクールなテクノロジーを楽しんで使っているNgx-Restangularを使用します

また、ngx-restangularは名前が示すようにRESTfulサービスでのみ機能することも知っておく必要があります。したがって、SOAPを提供するサービスでは、Ngx-Restangularを使用できません。

https://ngx-restangular.com/

そうは言って、私は常にngx-restangularを使用することになるので、いつも自分がクールだと思うプロジェクトに取り組み、自分が最善だと思うものを実装しようとしています。

がんばって!

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.