chore($http): remove deprecated responseInterceptors functionality

[caitp]

Code cleanup! response interceptors have been deprecated for some time, and it
is confusing to have two APIs, one of which is slightly "hidden" and hard to
see, which perform the same task. The newer API is a bit cleaner and more
visible, so this is naturally preferred.

BREAKING CHANGE:

Previously, it was possible to register a response interceptor like so:

// register the interceptor as a service
$provide.factory('myHttpInterceptor', function($q, dependency1,
  dependency2) {
  return function(promise) {
    return promise.then(function(response) {
      // do something on success
      return response;
    }, function(response) {
      // do something on error
      if (canRecover(response)) {
        return responseOrNewPromise
      }
      return $q.reject(response);
    });
  }
});

$httpProvider.responseInterceptors.push('myHttpInterceptor');

Now, one must use the newer API introduced in v1.1.4 (4ae4681), like so:

$provide.factory('myHttpInterceptor', function($q) {
  return {
    response: function(response) {
      // do something on success
      return response;
    },
    responseError: function(response) {
      // do something on error
      if (canRecover(response)) {
        return responseOrNewPromise
      }
      return $q.reject(response);
    }
  };
});

$httpProvider.interceptors.push('myHttpInterceptor');

Closes #7266

[petebacondarwin]

The last line of your "correct" code example should be:

$httpProvider.interceptors.push('myHttpInterceptor');

(Noting that the property is now interceptors)

Moreover I think the commit message should be more clear about the API change from "responseInterceptors" to "interceptors", which can also intercept "requests" as well as responses. In fact part of the beauty of them is that your interceptor can wrap a full request and response pair.

[caitp]

yeah, thats true, i'll fix the commit msg. That API has been deprecated for a long time though

[petebacondarwin]

LGTM

[caitp]

I guess if it's a chore, it won't show up in the changelog, and it belongs there. What would be a good type for this CL?

[caitp]

I guess it needs to be just manually added to the changelog. @btford will you be doing the next changelog update? If so can I get you to make a note to add this to it manually?

[btford]

Not sure if this should be marked as a chore. :/

@caitp: yes. I think it might also be good to amend the script to include breaking changes from chores.

[btford]

I verified that the changelog script does the right thing.

[caitp]

Okay, I agree that it probably shouldn't be marked as a chore, but I'm not sure of a better name for this type of commit.

If the changelog will show it anyways, then maybe it doesn't matter and should just be merged. SGTY?

[btford]

@caitp do it

[caitp]

Okay, done and done

[btford]

👍 🌟 👯