I came across this thread looking for something similar, but found that $resource will manage the cache for you automatically, so there's no need to force the cache to be cleared.
The idea is that if you have a resource that you can query, that query response will be cached, but if you save something for that same resource, the previously cached data must be invalid, so it is cleared for you. It makes sense that it would work this way.
Here's some code I use to do this (you can ignore the possibly odd-looking factory creation part and pay attention to the "class" body).
'use strict';
sampleApp.players.$ng.factory('sampleApp.players.PlayerService', [
'$log',
'$resource',
sampleApp.players.PlayerService = function ($log, $resource) {
var service = {};
$log.info('Creating player resource.');
var Player = $resource('/api/players', {}, {query: {
isArray: true,
cache: true,
method: 'GET'
}});
service.addPlayer = function(playerName) {
$log.info('Saving a new player.');
return new Player({name: playerName}).$save();
};
service.listPlayers = function () {
$log.info('Fetching players.');
return Player.query();
};
return service;
}]);
If you call the listPlayers function several times, the first call makes a http get request and all subsequent calls are cached. If you call addPlayer though, a http post is performed as expected, and then the next call to listPlayers will perform a http get (not cached).
This keeps you out of the business of managing someone else's ($http) cache and trying to keep up with which url's are being used for requests and which are clearing caches at the right times.
I suppose the moral of the story here is to work with the library and all will be well... except for any bugs or incomplete features, but Angular doesn't have any of those ;)
p.s. This is all running on AngularJS 1.2.0.
cache
-{boolean|Cache}
- Jeśli prawda, domyślna pamięć podręczna $ http zostanie użyta do buforowania żądania GET, w przeciwnym razie, jeśli instancja pamięci podręcznej zbudowana za pomocą