AngularJS $ httpおよび$ resource


257

呼び出したいWebサービスがいくつかあります。$resourceまたは$http、どちらを使用すればよいですか?

$resourcehttps : //docs.angularjs.org/api/ngResource/service/$resource

$httphttps : //docs.angularjs.org/api/ng/service/$http

上記の2つのAPIページを読んだ後、私は道に迷いました。

何が違うのか、どんな状況で使うべきなのかを分かりやすい英語で説明していただけませんか?これらの呼び出しを構造化し、結果をjsオブジェクトに正しく読み取るにはどうすればよいですか?


25
$ resourceは$ httpの上に構築され、基礎となる通信からのさらなる抽象化を提供します。また、$ resourceパターンに準拠するRESTエンドポイントも必要です。あなたが質問しているので、私の提案は$ httpから始めて、知り合いになり、後で$ resourceにシフトできるかどうかを確認することです。
David Riccitelli

4
答えてくれてありがとう。それで、APIに慣れることができることを除いて、$ httpは$ resourceよりも優先されますか?
トム

回答:


168

$http汎用AJAX用です。ほとんどの場合、これは使用するものです。では$http、あなたが作ることになるだろうGETPOSTDELETE種類を手動で呼び出し、処理、彼らは自分で返すオブジェクト。

$resource$httpRESTful Web APIシナリオで使用するためのラップ。


非常に一般的に言えば:AのRESTful WebサービスのようなHTTPメソッドに基づいて、そのデータ型と異なることを行い、データ型のためのエンドポイントを1つのサービスになりますGETPOSTPUTDELETEとなど、だから$resource、あなたが呼び出すことができGET、リソースを取得しますJavaScriptオブジェクトとして、それを変更してで送り返すPOSTか、で削除しDELETEます。

...それが理にかなっている場合。


1
つまり、$ resourceはRestfulサービスを処理します。つまり、通常のWebサービスの呼び出しにも使用できますか?GET POST DELETE PUTをすべて実行するためです。それでは、どのような状況で$ httpが$ resourceより優先されるのでしょうか?
トム

7
本当に安らぎのエンドポイントを扱っていないときはいつでも。たとえば、エンドポイントでGETのみが許可されている場合は、不要な多くの機能が追加されます。
Ben Lesh

@bleshので、使用し$resourceたサービスにのみ、あなたのRESTエンドポイントサポートしている場合は慣用的な/良いだろうGETPOST DELETE?ドキュメント(docs.angularjs.org/api/ngResource.$resource)は、これらの3つのRESTメソッドをで取得することを示しています$resource
ケビンメレディス2014年

9
@KevinMeredith:または任意の数のメソッド。あなたは追加することができますPUTまたはあなたが好きな何か、GETPOSTDELETEだけデフォルトです。複数のHTTPメソッドで同じリソース(重要)を処理するエンドポイントがある場合$resourceは、これが適切な選択です。
Ben Lesh 2014年

RESTfulでないエンドポイントの場合でも、GETおよびQUERYタイプのデータには$ resourceを使用すると便利です。与えられた方法は、ルーティングとバインディングに.$promise適しresolveています。
ケビン

210

他の答えは正しいですが、質問の根本を完全には説明していません。RESTはのサブセットですHTTP。介して行うことができます。この手段のすべてがRESTを介して行うことができますHTTPを介して行うことができますすべてのものではなく、HTTPを介して行うことができますREST。これが内部で$resource使用される理由$httpです。

それで、お互いをいつ使うのですか?

必要なものがすべてREST、つまり、RESTfulWeb サービスにアクセスしようとしている場合は、そのWeb サービス$resourceとの対話が非常に簡単になります。

代わりに、あなたがいないアクセスANYTHINGにしようとしている場合はRESTful、Webサービス、あなたが行かなければならないとしています$http。をRESTful介してWeb サービスにアクセスすることもできますが、を使用する$httpよりもはるかに煩雑になり$resourceます。これは、ほとんどの人がjQuery.ajax(Angularのと同等)を使用して、AngularJSの外部で行っている方法$httpです。


21
良い答えです、これは受け入れられるべきであり、上にあるものではありません
Andrzej Rehmann、2015年

2
RESTfulを呼び出すには3つの方法があるということですか?$ resource、$ http、jquery.ajaxを使用して、私は正しいですか?
Jake Huang、

4
@JakeHuangライブラリがなくても呼び出すことができます。呼び出す方法は無限です。AngularJSの世界で最も人気のある2つのアプローチと、それ以外の最も一般的なアプローチを公開しました。
bluehallu 2015

AngularJSで最も人気のある2つのアプローチは何ですか?:p
ジェイク・ファン

41

$http汎用のAJAX呼び出しを行います。これは、一般的にRESTful APIとNon-RESTful APIを含めることができることを意味します。

そして$resourceそのために特化されてRESTfulな部分。

プログラマーがランダムなURLを作成する代わりに、URLがよりよく整理されているため、Restful Apiは近年流行しています。

RESTful APIを使用してURLを作成すると、のようになり/api/cars/:carIdます。

$resource データを取得する方法

angular.module('myApp', ['ngResource'])

    // Service
    .factory('FooService', ['$resource', function($resource) {
        return $resource('/api/cars/:carId')
    }]);

    // Controller
    .controller('MainController', ['FooService', function(FooService){
        var self = this;
        self.cars = FooService.query();
        self.myCar = FooService.get('123');

    }]);

これはあなたを与えるだろうリソースオブジェクトを伴う、getsavequeryremovedelete自動的な方法を。

$http データを取得する方法

angular.module('myApp', [])

    // Service
    .factory('FooService', ['$http', function($http){
        return {
            query: function(){
                return $http.get('/api/cars');
            },

            get: function(){
                return $http.get('/api/cars/123');
            }
            // etc...
        }

RESTFul APIで各共通操作を定義する方法をご覧ください。また、1つの違いはすなわち$http戻りpromiseながら$resourceオブジェクトを返します。AngularがrestangularのようなRESTFul APIを処理するのを助けるサードパーティのプラグインもあります


APIがのようなものである場合/api/getcarsinfo。私たちに残されたすべては使用すること$httpです。


4
これは答えでなければなりません。
Royi Namir

1
APIが/api/getcarsinfo私がまだ使用できると思うなら$resource
Kittu

1
これは答えでなければなりません。「また、1つの違いは、$ httpがpromiseを返し、$ resourceがオブジェクトを返すことです」1-それは、.thenを$ resourceで使用する必要がないことを意味しますか?2-フロントエンドの人としても、これはばかげているように聞こえるかもしれませんが、APIが安静かどうかを確認するにはどうすればよいですか?感謝
シャリーフkhatab

1
@shireefkhatab 1.はい、$ resourceはRESTFul API connivenceのための$ httpのより高いレベルの抽象化です。ドキュメントの例では、それを使用する方法を示しています。2.それは完全にあなたのバックエンドの男がどのようにURLをデザインするかによる。彼がRESTFul APIパラダイムに準拠したい場合は、行ってもかまいません
Qiang

30

私は答えは誰にもっと依存だと思うあなたは、あなたがコードを書いている時点です。Angularを初めて使用$httpする場合は、必要な理由がわかるまで使用してください$resourceあなたはどのように具体的な経験を持つまで$http戻ってあなたを保持しているが、あなたが使用する意味を理解する$resourceには、あなたのコードで、スティックを$http

これは私の経験でした。私は最初のAngularプロジェクトを開始しました。RESTfulインターフェイスにHTTPリクエストを送信する必要があったので、今行っているのと同じ調査を行いました。このようなSOの質問で読んだディスカッションに基づいて、私はを選択しました$resourceこれは私が元に戻せるようにしたい間違いでした。理由は次のとおりです。

  1. $http例は豊富で、役立つものであり、一般的に必要なものだけです。明確$resourceな例は少なく、(私の経験では)必要なものがほとんどありません。Angularの初心者にとっては、ドキュメントに戸惑い、$resource手助けとなる有用な例が見つからないことに腹を立てるまで、選択の意味を理解することはできません。
  2. $httpおそらく、あなたが探しているものへの1対1のメンタルマップです。何が得られるかを理解するために、新しい概念を学ぶ必要はありません$http$resourceあなたがまだメンタルマップを持っていないという多くのニュアンスをもたらします。
  3. おっと、私はあなたが新しいコンセプトを学ぶ必要はないと言ったのですか?Angularの初心者は、約束について学ぶ必要あります。$http約束を返し、.thenそれが可能であるため、Angularと約束について学んでいる新しいこととぴったり合います。$resourceは、直接約束を返さないため、Angularファンダメンタルズの暫定的な把握を複雑にします。
  4. $resourceRESTful CRUD呼び出しのコードと入力および出力の変換を凝縮するため、強力です。$http自分の結果を処理するために繰り返しコードを書くことにうんざりしている場合、それは素晴らしいことです。他の誰にも、$resource紛らわしい構文とパラメーターの受け渡しの不可解なレイヤーを追加します。

3か月前に私のことを知っていたら$http良かったのですが、「子供にこだわるだけで結構です」と強調します。


1
私はあなたの答え、特に最後の行が好きです。私は現在、$ resourceと$ httpの使用をシフトしています。私が追加したいことの1つは、$ resourceは本当に便利なだけで、同じAPI 名詞/user/:userIdまたは)を使用しているときに実際に役立つことです/thing/users/roles/:roleId次に移動すると、動詞ごとに$ resource urlおよびparamsを変更する必要があり、その時点で$ httpを使用することもできます。
coblr 2016

3
自分の答えにコメントするために統合失調症と呼んでください。しかし、最近の経験については触れておきたいと思いました。私は、リファクタリングを行っ$resource$http、その場所を排除して切り替えることにしました。一度も会ったことがなかったらいいのに思うほど強調することはできません$resource。私はおそらく$resource何ヶ月にもわたるニュアンスを追いかけて1週間以上も無駄にしたことでしょう。$httpとても簡単でわかりやすいので、得られる利益$resourceは学習曲線によって完全に一掃されました。
Matthew Marichiba 2016年

24

$ resourceは生の文字列ではなくサーバーからの応答としてオブジェクトまたは配列を期待することを強調することが重要だと思います。したがって、応答として生の文字列(またはオブジェクトと配列以外のもの)がある場合は、$ httpを使用する必要があります。


これは、$ httpがオブジェクトと配列をサポートしていないことを意味しますか?明確にしたかっただけです。
Shardul

$ httpはオブジェクト、配列、文​​字列をサポートしていると思いますが、確認が必要です
Katana24

@Shardul、$ httpはあらゆる種類の応答を処理しますが、$ resourceはオブジェクトと配列のみを処理することを理解しました。
shireef khatab 2016年

真実ではありません。文字列を返すために$ resourceを使用できます。フロントエンドコードで 'transformResponse'を使用して、返された文字列をオブジェクトにラップします。
Terry Deng、

7

どちらを選択するか、$httpまたは$resource技術的に言えば、本質的に正しい答えも間違った答えもないので、どちらも同じことを行います。

の目的は$resource、パラメーター値とともにテンプレート文字列(プレースホルダーを含む文字列)を渡すことができるようにすることです。テンプレート文字列のプレースホルダーを、オブジェクトとして渡されるパラメーター値に$resource置き換えます。RESTFulデータソースと同様の原則を使用してURLを定義しているため、これはRESTFulデータソースと対話するときに主に役立ちます。

どのような$http行いは、非同期HTTP要求を実行することです。


1
これは、$ httpが$ resourceからの要求を強化するものであり、どちらも本質的に同じことを行うと指摘しているため、良い回答です。
coblr 2016

@Dalorzoでは$resource、非同期では実行できないと言うつもりですか?明確にしたかった
kittu

いいえ、私が指摘したのは、最後に$http非同期HTTPリクエストを実行する最も簡単な方法であり、$resource基本的に同じことを行いますが、パラメーターは異なります
Dalorzo

2

リソースサービスは、REST APSIを操作するための便利なサービスです。それを使用するときは、CRUDメソッド(作成、読み取り、更新、削除)を記述しません。

私が見る限り、リソースサービスは単なるショートカットであり、httpサービスで何でも実行できます。


$ resourceをショートカットとして分類するかどうかはわかりません。これは$ httpのラッパーなので、$ httpを直接使用すると「短く」なります。これは、$ httpを構成するときに、$ httpを使用するときにコードが少なくなる可能性がある方法です。ある場合$http.get('/path/to/thing', params)myResource.get(params)プラスの場合では、実際にの構成を行いますmyResource。より多くのコードを前もって追加し実際には同じ API名詞でのみスムーズに機能します。それ以外の場合は、$ httpを使用した場合と同じようにコーディングします。
coblr 2016

2

$ httpで$ resourceを使用するときに気付いたのは、.netでWeb APIを使用している場合です。

$ resourceは、単一の目的を実行する1つのコントローラーに結び付けられています。

$ resource( '/ user /:userId'、{userId: '@ id'});

[HttpGet]
public bool Get(int id)
{
    return "value"
}

public void Post([FromBody]string value)
{
}

public void Put(int id, [FromBody]string value)
{
}

public void Delete(int id)
{
}

$ httpは何でもかまいませんが。URLを指定するだけです。

$ http.get-"api / authenticate"

[HttpGet]
public bool Authenticate(string email, string password)
{
    return _authenticationService.LogIn(email, password, false);
}

それは私の意見です。


0

$ resourceサービスは現在、promiseをサポートしていないため、$ httpサービスとは明らかに異なるインターフェースを持っています。


1
$ resourceサービスはpromiseをサポートしますが、$ httpのように直接$ promiseを返しません。あなたはそれをあなたがするvar myResource = $resource(...config...);サービスのどこか他の場所と同じようにしなければならない、return myResource.get(..params...)またはあなたができるvar save = myResource.save(); save.$promise.then(...fn...); return save;
coblr
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.