ngResource
déjà semble très simple mettre en oeuvre des choses avec ...
Quels sont les avantages/inconvénients de l’utilisation de Restangular over ngResource ?
1.1.3 $resource
retournera les promesses et pourra être implémenté en utilisant latest PR commit . Une assistance future sera-t-elle proposée à $resource
pour prendre en charge des verbes supplémentaires proposés par Restangular? Et si cela se produit, Restangular semble disparaître et devenir irrélivant.
Je suis le créateur de Restangular.
J'ai créé une section sur README avec les différences par rapport à $ resource. Vous pouvez les vérifier ici https://github.com/mgonto/restangular/blob/master/README.md#differences-with-resource
Quoi qu'il en soit, en résumé, outre les fonctionnalités supplémentaires et l'approche basée sur les promesses, l'idée est que Restangular peut également gérer toutes vos URL, de sorte que vous ne devez rien savoir à leur sujet.
Supposons que vous ayez quelque chose comme ceci pour les voitures:/users/123/cars/456
Dans $ resource, vous devez construire cette URL manuellement et vous devez également construire l'objet $ resource pour cela manuellement. Restangular vous aide dans cette tâche en "mémorisant" les URL.
Donc, si vous faites dans un endroit
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')
J'espère que cela t'aides!
J'ai trouvé le RequestInterceptor de Restangular assez pratique pour supprimer certains champs de l'objet avant de faire la demande. La plupart des REST services Web avec lesquels je travaille actuellement n'attendent pas l'identifiant dans les données d'objet dans une demande PUT, par exemple, uniquement dans l'URL. Généralement, ils ne s'attendent pas à des champs de données supplémentaires qui ne peuvent pas être mis à jour par PUT (comme l'id ou un slug généré en définissant le titre, etc.). J'ai trouvé que cela était simple avec Restangular, alors que je ne savais pas comment le faire avec des ressources propres, mais je suis sûr que c'est possible d'une manière ou d'une autre.
Évidemment, on pourrait aussi changer le service Web pour simplement ignorer ces champs supplémentaires, mais ce n’est pas toujours possible.
ngResource ne renvoie pas de promesses dans la dernière version stable (actuellement 1.0.6). De plus, il semble que Restangular expose plus de verbes que ngResource (il expose PUT, OPTIONS, PATCH, etc.).
Si vous n'avez pas besoin des verbes supplémentaires et que vous vous trouvez dans la branche instable d'AngularJS (qui inclut des promesses pour ngResource), je ne vois aucune raison majeure d'utiliser Restangular sur ngResource.
Utilisez ce que vous sentez à l'aise.
Pour donner suite aux réponses ci-dessus et aux (nouvelles) lecteurs, comme moi, intéressés par ces réflexions:
"Et si cela se produit, Restangular semble disparaître pour devenir irrélivant."
"Que se passe-t-il dans trois mois lorsque ce gars lâche le support pour Restangular parce que le ngResource de Google a rattrapé toutes les fonctionnalités Il manquait."
A mon avis, la seule garantie à la survie d'une bibliothèque open-source est la communauté construite autour d'elle. Un meilleur exemple serait mariaDB _ et WebScaleSQL dont les deux sont nés en tant que branche croissante du grand système de gestion de base de données relationnelle MySQL.
À ce moment-ci, Restangular having 6699 stars and 727 forks
est en train de passer à Restangular 2.0, destiné à supporter angularJs 2.0 et ES6.
Pour un site Web simple et rapide que vous souhaitez exploiter à tout jamais avec le minimum de support, j'utiliserais le http HttpClient angulaire intégré [], peu importe quand je travaille sur un projet que j'aime et que j'apprécie et tente d'utiliser toutes les technologies cool alors je vais utiliser Ngx-Restangular
Vous devez également savoir que ngx-restangular fonctionne avec les services RESTful uniquement, comme son nom l’indique. Donc, pour les services qui fournissent SOAP, vous ne pourrez pas utiliser Ngx-Restangular
Ceci étant dit j'utiliserais presque toujours ngx-restangular, car j'essaie toujours de travailler sur un projet que je trouve cool et d'essayer de mettre en œuvre ce que je considère être le meilleur.
Bonne chance!