feat($http): Pass http config to response interceptors

[thelvey]

Allow response interceptors to use the config object passed to the
$http call that the response originated from

---

This arose from a use case where I needed a global loading indicator with loading messages that were customized for each endpoint.

Here is a jsfiddle I created that demonstrates this use case with a build of angular including this change: http://jsfiddle.net/ashelvey/UJ2Xx/

You can use Charles, Fiddler, etc.. to throttle http calls for a more realistic demo.

(CLA signed)

[petebacondarwin]

This use case would be solved by the addition of a httpRequestInterceptor: See #1701

[thelvey]

Yes, request interceptors will be nice to have and would handle a simple solution like what I put together in the fiddle.

In the real life implementation where we handle concurrent requests, grace period before showing an indicator, etc... we still want to be able to handle it on the response side with access to the config.

[petebacondarwin]

Isn't the RequestInterceptor solution more capable than providing config?

They will be resolved around the same time as the ResponseInterceptor function is called and can be chained to provide transformations to the request.

Your example of a grace period could be implemented with a RequestInterceptor. In fact if you chose to use the request object (i.e. the config object) to pass info to the ResponseInterceptor handler then it would be functionally equivalent.

The only thing that it would not provide simply is to have a closure variable to pass stuff to the ResponseInterceptor handler.

[thelvey]

Here's another fiddle with a little more happening in the response interceptor: http://jsfiddle.net/ashelvey/TPvBJ/

This one has multiple loading messages that are conscious enough to only dismiss themselves individually without affecting other instances of loading messages.

In this case, it needs to have the config at the time the response promise is resolved to properly handle removing the one specific message tied to that $http call. (Rather than just blindly getting rid of the message at the point the promise is resolved.)

I think we're kind of getting distracted with the use case though. There are other reasons I've found it useful to have the config context in the response interceptors. If for nothing else, for ease of debugging and tracing. I don't see any risk here and have personally found it useful.

[IgorMinar]

I've just spent 1.5h looking at this together with @pkozlowski-opensource and we realized that the best option would be to implement "around interceptors" for http. This would solve all use-cases discussed here as well as open up a whole lot of new possibilities.

An example of an around interceptor would look something like this (this work in progress):

myApp.factory('myAroundInterceptor', function($rootScope, $timeout) {
    return function(configPromise, responsePromise) {
        return {
            config: configPromise.then(function(config) {
                return config
            });
            response: responsePromise.then(function(response) {
                return 'ha!';
            }
        });
}

myApp.config(function($httpProvider){
    $httpProvider.aroundInterceptors.push('myAroundInterceptor'); 
});

we are likely going to implement these interceptors in favor of request interceptors that are being discussed in PR #1701

thanks for the proposal.