Why doesn't Web API come with caching features like MVC actions?
Is it because these are HTTP based services so no state in between calls?
I have seen a few open sources like CacheCow and Strathweb, but not sure whom to pick and why?
What are the best and standard options for caching with ASP.NET Web API?
This is an extensive article that explains the principal options, and contains links to many more information:
EXPLORING WEB API 2 CACHING
It includes information about:
CacheCow, explained also in this article by Scott Hanselmman.
AspNetWebApi-OutputCache
Your own implementation
The poor man's implementation consist in:
implement a cache store that supports storing and retrieving values by key
generate a key from the request properties, like action parameters, method, headers, and so on, to generate a key
check if a value for that key is available in the cache store:
if it is available, return it
if it isn't generate it, store it and return it
var result = cacheStore.GetValue(keyFromRequest);
if (result == null)
{
result = MyClass.ExpensiveFunctionCall(params);
cacheStore.Store(keyFromRequest, result);
}
return result;
The cache store can be, for example, a database, a memory cache like MemoryCache class, or a Redis server.
The evolution of this idea is to use MVC action filters to make this cache cheking automatic, or to use a fully implemented solution like the aforementioned CacheCow
Related
I've got a webAPI that uses Entity Framework. I'm trying to cache some data in the session variable following along in this article:
https://msdn.microsoft.com/en-us/library/system.web.httpcontext.session(v=vs.110).aspx
I can't seem to do it though. The Session object isn't available.
In my controller, I try this:
Session["mappings"] = mappings;
...but it doesn't recognize what Session is.
I also try this:
HttpContext.Current.Session["mappings"] = mappings;
...and this:
Page.Session["mappings"] = mappings;
...but it doesn't know what HttpContext or Page are.
I'm including System.Web in my project references. I'm also including this in my web.config:
...just like this article says:
https://msdn.microsoft.com/en-us/library/ms178581(v=vs.110).aspx
...but to no avail.
My work colleague suggests it's because our webAPI is RESTful which means it's stateless, so no session object. However, we know there are ways around this. What I need is simply some way of persisting data in some kind of cache that will survive across several requests.
I also need something that will be available inside EF entities (not just the webAPI controller) is that's possible.
Does anyone know how to solve this problem? Thanks.
As your colleagues correctly suggested, an API is stateless, each request is separate and needs to have all the data required to complete the request.
You can add a caching layer however, but that is not going to be done via the Session object. Session makes no sense in an API.
Have a look here for some ideas: Caching Data in Web API
I am looking for a cache implementation for an Angular2 application.
For example, we have a million Movie objects stored on a server (i.e. enough that we don't want to grab them all at once). On the server, a REST endpoint is available : getMovie(String id)
Back on the client side, the cache should provide a simple way to get a movie from Angular, something like cache.getMovie(id:string): Observable<Movie>. This will hit the REST endpoint only for the first call, and store it locally for later requests.
Angular1 has angular-cache or the $cacheFactory, with LRU support and other great functionalities.
I started implementing a basic cache using a local HashMap, but that seems like a very common need.
Is there a good in-memory cache implementation for Angular2 yet?
I would use lscache and extend it providing few underlying storages: localStorage, sessionStorage, and self-implmented memoryStorage. TypeScript definitions are already available.
In MVC and most other service frameworks I tried, caching is done via attribute/filter, either on the controller/action or request, and can be controlled through caching profile in config file. It seems offer more flexibility and also leave the core service code cleaner.
But ServiceStack has it inside the service. Are there any reason why it's done this way?
Can I add a CacheFilterAttribute, but delegate to service instead?
ToOptimizedResultUsingCache(base.Cache,cacheKey,()=> {
// Delegate to Request/Service being decorated?
});
I searched around but couldn't find an answer. Granted, it probably won't make much difference because the ServiceStack caching via delegate method is quite clean. And you seldom change caching strategy on the fly in real world. So this is mostly out of curiosity. Thanks.
Because the caching pattern involves, checking first to see if it is cached, if not to then execute the service, populate the cache, then return the result.
A Request Filter doesn't allow you to execute the service and a Response Filter means that the Service will always execute (i.e. mitigating the usefulness of the Cache), so the alternative would require a Request + Response filter combination where the logic would be split into 2 disjointed parts. Having it inside the Service, lets you see and reason about how it works and what exactly is going on, it also allows full access to calculate the uniqueHashKey used and exactly what and when (or even if) to Cache, which is harder to control with a generic black-box caching solution.
Although we are open to 'baking-in' built-in generic caching solutions (either via an attribute or ServiceRunner / base class). Add a feature request if you'd like to see this, specifying the preferred functionality/use-case (e.g. cache based on Time / Validity / Cache against user-defined Aggregate root / etc).
Background: We are using grails 2.1.1. We are not using any DB as of now. We make a web service call for each response on another server.
Now the problem is, there is web service call which returns some static data in XML form and this data is usable throughout the application. The size of the xml is around 40kb. This xml contains static data like, project_list, status_type_list etc. and we have to use this in various dropdowns and menu items in different gsp pages.
So, please suggest us the best way to handle this data. So that it doesn't effect our page load time and browsing experience. And also we can easily use the data on client side.
responding to your comment on the question. I would prefer using annotation based caching over the plugin, if the requirement is as simple as you state that it is.
If the calls are being made from server-side and you want to cache the results of the parsed XML then you can do something like:
#Cacheable("staticDataCache")
def getStaticDataFromXML() {}
You can then use the above method to pull the maps, lists whatever data structure you've used to store the result and it will pull it from the cache.
and then another service method to flush the cache, which you can call frequently from a Job.
#CacheFlush("staticDataCache")
def flushStaticDataCache() {}
Use the cache plugin to cache the static xml data. And then add some policy as to when the cache should be updated... (i.e. using a job to check if the xml has changed every hour)
This article suggests it was possible, or in the works, with some code that suggests it can be done, but I can't figure out what code needs to happen or the WcfTestClient's uri needs to be.
Here's the code from the article that makes me think I can do it:
// Metadata routes to support $metadata and code generation in the WCF Data Service client.
configuration.Routes.MapHttpRoute(
ODataRouteNames.Metadata,
"$metadata",
new { Controller = "ODataMetadata", Action = "GetMetadata" }
);
Is this feature implemented?
No, it does not work as you intend. WCF Test Client supports talking to SOAP-based services. OData is not supported in the current version.
Granted, as #Snixtor mentioned, you could create a SOAP service using ASP.NET Web API, including support for metadata (WSDL). But I really don't know of any good reason why anyone would want to do that.