Because AJAX requests are asynchronous, things can get a little hairy when you have several AJAX requests running at the same time. You have no way of knowing the order in which the requests will return. For this reason, being able to explicitly "abort" an unwanted AJAX request can make your life a lot easier.
Consider a simple List-Detail interface in which a user can select an item and view the item's detail. If the detail information has to be retrieved using an asynchronous method (ex, AJAX), the user may be able to click on several list items before the first request is resolved. This may end up leaving your View-Model in an unexpected state.
To demonstrate, I've put together a small app that presents a list of friends. If you click on a friend, the client will make a request to the server to gather the detail information before AngularJS renders it on the page. The caveat, in this case, being that the API will "sleep" all API requests for an unequal amount of time. This allows us to create an "unexpected" order of request resolutions.
To manage this problem, we have to keep track of the currently-executing AJAX request. This way, when we go to make a new AJAX request, we can abort the pending request so that it doesn't end up invoking our data resolution / success handlers.
As you can see, whenever we initiate a request, we first call .abort() on the current request. This will make sure the current request is "rejected" and the new AJAX request is the only one running.
If I were to comment-out the .abort() call, we could end up with a page that looks like this:
Notice that our UI is rendering "Tricia" (ID:3) even though "Kim" (ID:1) was the last request made. This is because the request for (ID:1) resolved before the request for (ID:3) even though the request for (ID:3) was initiated first. Had we aborted the first request when we made the second request, our UI would be rendered properly.
If you're on an earlier version of AngularJS, before the timeout property could be used to abort the underlying AJAX request, you can still manage this problem, just not as easily. Solutions range from the not great - using something like ng-if / ui-if to completely destroy and rebuild the View anytime an ID changes - to the merely inconvenient - checking the response data against the current View-Model to make sure they are in alignment. It works, but it's a headache.
In addition to avoiding race conditions in asynchronous requests, aborting the underlying request can be helpful when your current $scope is destroyed. I've talked about this before, in terms of canceling a $timeout callback, but same applies to AJAX requests; when your $scope is destroyed, you should abort any relevant AJAX request or the eventual request resolution (or rejection) may end up generating an unexpected user experience.
All to say, I've added an .abort() method to my httpi AngularJS module.
Want to use code from this post? Check out the license.