AngularJS $ http et $ resource

J'ai quelques services Web que je veux appeler. $resourceou $httplequel dois-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 s'il vous plaît m'expliquer en anglais simple quelle est la différence et dans quelle situation dois-je les utiliser? Comment structurer ces appels et lire correctement les résultats dans des objets js?

$httpest à usage général AJAX. Dans la plupart des cas, c'est ce que vous utiliserez. Avec $httpvous allez faire GET, POST, le DELETEtype appelle manuellement et traiter les objets qu'ils reviennent sur votre propre.

$resourceencapsule $httpà utiliser dans les scénarios d'API Web RESTful.

De façon très générale: Un service Web RESTful sera un service avec un point final pour un type de données qui fait des choses différentes avec ce type de données basées sur des méthodes HTTP aiment GET, POST, PUT, DELETE, etc. Donc , avec un $resource, vous pouvez appeler GETpour obtenir la ressource en tant qu'objet JavaScript, puis modifiez-le et renvoyez-le avec un POST, ou même supprimez-le avec DELETE.

... si ça a du sens.

Je pense que d'autres réponses, bien que correctes, n'expliquent pas tout à fait la racine de la question: RESTest un sous-ensemble de HTTP. Cela signifie que tout ce qui peut être fait via RESTpeut être fait via HTTPmais pas tout ce qui peut être fait via HTTPne peut pas être fait via REST. C'est pourquoi $resourceutilise en $httpinterne.

Alors, quand utiliser les uns les autres?

Si tout ce dont vous avez besoin REST, c'est que vous essayez d'accéder à un service RESTfulWeb, $resourcerendra l'interaction avec ce service Web très facile.

Si, à la place, vous essayez d'accéder à TOUT ce qui n'est pas un service RESTfulWeb, vous devrez y aller $http. Gardez à l'esprit que vous pouvez également accéder à un service RESTfulWeb via $http, il sera juste beaucoup plus lourd qu'avec $resource. C'est la façon dont la plupart des gens l'ont fait en dehors d'AngularJS, en utilisant jQuery.ajax(l'équivalent d'Angular $http).

$httpeffectue un appel AJAX à usage général, ce qui signifie généralement qu'il peut inclure une API RESTful plus une API non RESTful .

et $resourceest 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'une URL aléatoire composée par des programmeurs.

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

$resource façon 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 , qui est accompagné get, save, query, remove, deleteméthodes automatiquement.

$http façon 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...
        }

Découvrez comment nous devons définir chaque opération commune sur l' API RESTFul . Une différence est également que $httprenvoie promisewhile $resourcerenvoie un objet. Il existe également des plugins tiers pour aider Angular à gérer l'API RESTFul comme restangular

Si l'API ressemble à quelque chose /api/getcarsinfo. Il ne nous reste plus qu'à utiliser $http.

Je pense que la réponse dépend davantage de qui vous êtes au moment où vous écrivez le code. À utiliser $httpsi vous débutez avec Angular, jusqu'à ce que vous sachiez pourquoi vous en avez besoin $resource. Jusqu'à ce que vous ayez une expérience concrète de la façon dont $httpvous vous retenez et que vous compreniez les implications de l'utilisation $resourcedans votre code , restez avec $http.

Ce fut mon expérience: j'ai commencé mon premier projet Angular, j'avais besoin de faire des requêtes HTTP à une interface RESTful, donc j'ai fait la même recherche que vous faites maintenant. Sur la base de la discussion que j'ai lue dans des questions SO comme celle-ci, j'ai choisi d'y aller $resource. C'était une erreur que j'aurais aimé pouvoir annuler. Voici pourquoi:

1. $httples exemples sont nombreux, utiles et généralement juste ce dont vous avez besoin. Les $resourceexemples clairs sont rares et (selon mon expérience) rarement tout ce dont vous avez besoin. Pour le débutant Angular, vous ne réaliserez les implications de votre choix que plus tard, lorsque vous serez coincé par la documentation et en colère de ne pas trouver d' $resourceexemples utiles pour vous aider.
2. $httpest probablement une carte mentale 1 à 1 de ce que vous recherchez. Vous n'avez pas besoin d'apprendre un nouveau concept pour comprendre ce que vous obtenez $http.$resourceapporte beaucoup de nuances pour lesquelles vous n'avez pas encore de carte mentale.
3. Oups, ai-je dit que vous n'avez pas à apprendre un nouveau concept? En tant que débutant angulaire vous ne devez en apprendre davantage sur les promesses. $httprenvoie une promesse et est .thencapable, donc il s'intègre parfaitement avec les nouvelles choses que vous apprenez sur Angular et les promesses. $resource, qui ne renvoie pas directement une promesse, complique votre compréhension provisoire des fondamentaux angulaires.
4. $resourceest puissant car il condense le code des appels RESTful CRUD et les transformations d'entrée et de sortie. C'est génial si vous en avez marre d'écrire à plusieurs reprises du code pour traiter les résultats de $httpvous - même. Pour quelqu'un d'autre, $resourceajoute une couche cryptique de syntaxe et de passage de paramètres qui prête à confusion.

J'aimerais bien me connaître il y a 3 mois, et je me dirais avec emphase: "Reste avec l' $httpenfant. C'est très bien."

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

Quand il s'agit de choisir entre $httpou $resourcetechniquement parlant, il n'y a pas de bonne ou de mauvaise réponse, les deux feront la même chose.

Le but de $resourceest de vous permettre de passer une chaîne de modèle (une chaîne qui contient des espaces réservés) avec les valeurs des paramètres. $resourceremplacera les espaces réservés de la chaîne de modèle par les valeurs de paramètre celles transmises en tant qu'objet. Cela est surtout utile lors de l'interaction avec la source de données RESTFul car ils utilisent des principes similaires pour définir les URL.

Qu'est $http- ce que c'est, c'est d'exécuter les requêtes HTTP asynchrones.

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

Pour autant que je le vois, le service de ressources n'est qu'un raccourci, vous pouvez tout faire avec le service http.

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é à un contrôleur qui exécute un seul objectif.

$ 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. spécifiez simplement 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.

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