134

ngResourceすでに物事を実装するのは本当に簡単に思えます...

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

1.1.3は promise を返し、最新の PR commit$resourceを使用して実装できます。Restangular が行う追加の動詞をサポートするために、将来のサポートが提供されますか? そうなったらRestangularは消えて無くなってしまいそうです。$resource

4

5 に答える 5

232

私は Restangular の作成者です。

$resource との違いを記載した README セクションを作成しました。ここで確認できます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')

お役に立てれば！

于 2013-05-23T21:55:30.413 に答える
8

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

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

于 2013-12-04T12:26:27.200 に答える
3

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

追加の動詞が必要なく、AngularJS の不安定なブランチ (ngResource の約束を含む) を使用している場合、ngResource ではなく Restangular を使用する主な理由はないと思います。

使いやすいと思うものを使用してください。

于 2013-05-15T00:05:05.600 に答える