web-dev-qa-db-fra.com

AngularJS $ http et $ resource

J'ai quelques services Web que je veux appeler. $resource ou $http, lequel devrais-je utiliser?

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

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

Après avoir lu les deux pages API ci-dessus, je suis perdu.

Pourriez-vous m'expliquer en termes clairs quelle est la différence et dans quelle situation dois-je les utiliser? Comment structurer ces appels et lire les résultats dans des objets js correctement?

javascriptweb-servicesangularjs
257
Tom

$http est pour AJAX à usage général. Dans la plupart des cas, c'est ce que vous utiliserez. Avec $http vous allez faire GET, POST, DELETE saisir les appels manuellement et traiter les objets qu’ils renvoient vous-même.

$resource encapsule $http pour une utilisation dans les scénarios d'API Web RESTful.

En général, un service Web RESTful est un service avec un point de terminaison pour un type de données qui effectue différentes tâches avec ce type de données en fonction de méthodes HTTP telles que GET, POST, PUT, DELETE, etc. Donc avec un $resource, vous pouvez appeler un GET pour obtenir la ressource en tant qu'objet JavaScript, puis le modifier et le renvoyer avec un POST, ou même le supprimer avec DELETE.

... si ça a du sens.

167
Ben Lesh

Je pense que les autres réponses, bien que correctes, n'expliquent pas tout à fait la racine de la question: REST est un sous-ensemble de HTTP. Cela signifie que tout ce qui peut être fait via REST peut être fait via HTTP mais que tout ce qui peut être fait via HTTP ne peut pas être fait via REST. C'est pourquoi $resource utilise $http en interne.

Alors, quand se servir les uns les autres?

Si tout ce dont vous avez besoin est REST, c’est-à-dire que vous essayez d’accéder à un RESTful service Web, $resource va faciliter l’interaction avec ce service Web.

Si au lieu de cela, vous essayez d'accéder à tout ce qui n'est pas un service Web RESTful, vous devrez utiliser $http. N'oubliez pas que vous pouvez également accéder à un RESTful Webservice via $http, il sera simplement beaucoup plus lourd que avec $resource. C'est comme cela que la plupart des gens l'ont fait en dehors d'AngularJS, en utilisant jQuery.ajax (équivalent du $http d'Angular).

210
bluehallu

$http effectue un appel général AJAX, dans lequel général signifie qu'il peut inclure RESTful api plus non apaisant api.

et $resource est spécialisé pour cette partie RESTful .

Api reposant est devenu répandu ces dernières années parce que l'URL est mieux organisée au lieu d'URL aléatoire constituée par les programmeurs.

Si j'utilise une API RESTful pour construire l'URL, ce sera quelque chose comme /api/cars/:carId.

$resource moyen de récupérer des données

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');

    }]);

Cela vous donnera un objet ressource , accompagné de get, save, query, remove, delete méthodes automatiquement .

$http moyen de récupérer des données

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...
        }

Voyez comment nous devons définir chaque opération commune sur API RESTFul . De plus, une différence est que $http renvoie promise alors que $resource renvoie un objet. Il existe également des plug-ins tiers pour aider Angular à gérer API RESTFul comme restangulaire

Si l'API est quelque chose comme /api/getcarsinfo. Tout ce qui nous reste à faire est d'utiliser $http.

41
Qiang

Je pense que la réponse dépend plus de qui vous êtes au moment où vous écrivez le code. tilisez $http si vous êtes nouveau dans Angular, jusqu'à ce que vous sachiez pourquoi vous avez besoin de $resource. Jusqu'à ce que vous ayez une expérience concrète de la façon dont $http vous retient, et vous comprenez les implications de l’utilisation de $resource dans votre code , restez-y à $http.

C’est ce que j’ai vécu: j’ai lancé mon premier projet Angular, je devais adresser des requêtes HTTP à une interface RESTful et j’ai donc effectué les mêmes recherches que vous. D'après la discussion que j'ai lue dans SO questions comme celle-ci, j'ai choisi d'aller avec $resource. C’était une erreur que je voudrais pouvoir annuler. Voici pourquoi:

  1. $http les exemples sont nombreux, utiles et correspondent généralement à vos besoins. Effacer $resource exemples sont rares, et (selon mon expérience) rarement tout ce dont vous avez besoin. Pour le débutant Angular, vous ne réaliserez les conséquences de votre choix que plus tard, lorsque vous resterez perplexe devant la documentation et en colère que vous ne trouviez aucune aide utile $resource exemples d'aide. tu sors.
  2. $http est probablement une carte mentale un-à-un avec ce que vous recherchez. Vous n'avez pas besoin d'apprendre un nouveau concept pour comprendre ce que vous obtenez avec $http. $resource apporte beaucoup de nuances pour lesquelles vous n'avez pas encore de carte mentale.
  3. Oups, ai-je dit que vous n'aviez pas à apprendre un nouveau concept? En tant que Angular débutant, vous faites devez en savoir plus sur les promesses. $http renvoie une promesse et est .thenable, de sorte qu'il s'adapte parfaitement aux nouvelles choses que vous apprenez sur Angular et aux promesses. $resource, qui ne retourne pas directement une promesse, complique votre compréhension provisoire sur les fondamentaux de Angular.
  4. $resource est puissant, car il condense le code pour les appels RESTful CRUD et les transformations pour les entrées et les sorties. C’est génial si vous en avez assez d’écrire du code pour traiter les résultats de $http vous-même. À qui que ce soit d'autre, $resource ajoute une couche cryptique de syntaxe et de transmission de paramètres qui prête à confusion.

J'aurais aimé me connaître il y a trois mois et je me dirais avec force: "Tenez-vous-en-tête avec le $http kid. C'est parfait."

30
Matthew Marichiba

Je pense qu'il est important de souligner que $ resource attend un objet ou un tableau en réponse du serveur, pas une chaîne brute. Donc, si vous avez une chaîne brute (ou tout sauf objet et tableau) en réponse, vous devez utiliser $ http

24
sparrkli

Lorsqu'il s'agit de choisir entre _$http_ ou _$resource_ techniquement parlant, il n'y a pas de bonne ou de mauvaise réponse, mais les deux feront essentiellement la même chose.

Le but de _$resource_ est de vous permettre de transmettre une chaîne de modèle (une chaîne contenant des espaces réservés) avec les valeurs de paramètres. _$resource_ remplacera les espaces réservés de la chaîne de modèle par les valeurs de paramètre transmises en tant qu'objet. Cela est surtout utile lors de l'interaction avec la source de données RESTFul, qui utilise des principes similaires pour définir les URL.

Ce que _$http_ fait, c'est exécuter les requêtes HTTP asynchrones.

7
Dalorzo

service de ressources est juste un service utile pour travailler avec REST APSI. lorsque vous l'utilisez, vous n'écrivez pas vos méthodes CRUD (créer, lire, mettre à jour et supprimer)

D'après ce que je vois, le service de ressources n'est qu'un raccourci, vous pouvez faire n'importe quoi avec le service http.

2
john Smith

Une chose que j’ai remarquée lors de l’utilisation de $ resource sur $ http est que vous utilisez l’API Web dans .net

$ resource est liée à un contrôleur qui exécute un seul but.

$ 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)
{
}

Alors que $ http pourrait être de n'importe quoi. il suffit de spécifier l'URL.

$ http.get - "api/authenticate"

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

c'est juste mon avis.

2
jayson.centeno

Le service $ resource ne prend actuellement pas en charge les promesses et possède donc une interface distinctement différente du service $ http.

0
firdous