Je voudrais pouvoir capturer toutes les requêtes et réponses HTTP, et les modifier, avant d'accéder au reste d'une application EmberJs. Je voudrais le faire globalement – sur l'ensemble de l'application. Je n'ai pas pu trouver ce creusement dans l'API . Comment cela peut-il être fait?
(La modification consiste à effectuer une logique conditionnelle basée sur certains en-têtes ou à ajouter ou à modifier certains en-têtes).
Dans AngularJS, vous pouvez accomplir ceci en utilisant quelque chose comme ceci:
App.factory('AppHttpInterceptor', function($q) { return { request: function(req) { //modify request return req; }, response: function(res) { // modify response return res || $q.when(res); } }; }); App.config(function ($httpProvider) { $httpProvider.interceptors.push('AppHttpInterceptor'); });
Tout d'abord, il est important de noter que Angular et Ember ne sont pas conçus pour servir le même but. Ils sont tous deux des frameworks javascript, et c'est à peu près l'endroit où les similitudes finissent. Un autre facteur important dans la différence des demandes asynchrones dans le cadre de deux est l'intégration d'Angular des promesses dans ses services asynchrones. Les services asynchrones Ember ne sont pas basés sur les promesses, et donc les intercepteurs de réponse ne sont pas possibles (voir ma note ci-dessous).
AngularJS fournit $httpProvider
comme singleton configurable qui renvoie une instance configurée de $http
comme un objet prometteur . Angular se concentre sur les services plutôt que sur les méthodes (bien qu'il ait quelques méthodes qu'il vous donne), et c'est ce qui distingue Angular des autres frameworks comme Ember, qui vous donnent une structure pour créer des services, mais ne fournit pas de services dans son cœur .
Au lieu de cela, avec Ember, vous devriez créer un concept de service et de fournisseur de services. Vous pouvez prendre quelque chose comme cerebris / ember-repos , et l'étendre de manière à utiliser les propriétés que vous décrivez. Cette bibliothèque fournit une méthode Ember.resource
, que vous pourriez utiliser comme prototype pour étendre à partir de là:
Ember.ResourceAdapter.extend({ _prepareResourceRequest: function(params) { params.beforeSend = function (xhr, settings) { //set your xhr interceptors here } } });
$ajax
en braise et $http
en Angulaire (promesses vs rappels) La plus grande différence sur la façon dont les intercepteurs de réponse angulaires rend possible, c'est que les demandes asynchrones en angulaire sont des promises
, alors que les appels $ajax
ne sont pas. Sans trop entrer dans les mauvaises herbes, vous pouvez affecter des variables à chaque étape d'une promesse, en la rendant disponible pour la mutation / la manipulation à chaque étape, alors qu'avec $ajax
, vous ne pouvez effectuer que des opérations lorsque les données sont complètement retournées. Avec Promises, affectez des variables pour représenter les états à n'importe quel moment pendant le cycle de vie de la promesse, et en utilisant cette référence, vous pouvez muter la promesse au besoin, à tout moment avant l'événement de la promesse de résoudre complètement.
Ainsi, pourquoi il est possible de faire des intercepteurs de requêtes avec $ajaxPrefilter
mais il n'y a pas de bon moyen d'intercepteurs de réponse , en utilisant l'approche de configuration abstraite avec $ajax
. Pour vraiment faire chez Ember ce que AngularJS fait avec $http
, vous devez créer un service de demande / réponse asynchique basé sur les promesses, par opposition à l'utilisation de demandes xhr basées sur des promesses telles que $ajax
.
$ajaxSetup()
fournit une $ajaxSetup()
, que vous pourriez pouvoir définir une propriété dataFilter
et définir une fonction de gestionnaire, mais ceci n'est pas recommandé. Avec angular, le $httpProvider
peut être configuré par module, et par $httpProvider
et séparation des préoccupations, cela peut devenir vraiment puissant, vous permettant d'encapsuler et de mettre en cascade les configurations d'intercepteurs http avec beaucoup de contrôle. Les mêmes modifications apportées à vos paramètres ajax s'inscriront sur l'espace de noms global jquery et peuvent causer des conflits si vous devez développer votre application.
Une vidéo que j'ai trouvée particulièrement intéressante sur ce sujet était de ng-conf 2014: Christion Lilley: Going Postal with Angular Promises
Alors que Ember.RSVP
est en effet une classe prometteuse utilisable dans le cadre, il n'a pas de méthodes disponibles pour effectuer des demandes de ressources. Cela signifie que vous devez assigner manuellement une instance de demande http à une instance de RSVP.deferred telle qu'elle résout votre demande http avant de renvoyer la promesse.
Cela vous permet de faire des intercepteurs des deux côtés de chaque demande individuelle, mais ne fournit pas une solution pour configurer les intercepteurs pour toutes les demandes. Vous devriez créer une autre fonction ou service pour cela, et étendre RSVP avec cette fonction.