Series Navigation Address http://www.cnblogs.com/fzrain/p/3490137.html
This article uses an open-source framework, CacheCow, to implement resource caching for Http requests. This article mainly introduces server-side caching.
The cache technology can improve the performance of Web APIs and reduce the server overhead. We call this cache form Conditional request (Conditional Requests ). Specifically, the client attaches a request header ETag to the server, and then the server determines whether to send the updated resource to the client based on the information. If necessary, returns status 200 and resource content. Otherwise, the system responds to status code 304 (Not modified) and an empty response body.
So what is ETag? ETag is a unique identifier (string type) generated by the server for a specific resource ). You can also check whether the server resources have changed.
ETag has two types: strong and weak. Weak ETag contains a prefix W (for example, W/53fsfsd322), while strong ETag does not contain any prefix (for example, 53fsfsd322 ). In general, the weak type ETag indicates the cache of short-time resources (memory cache), while the strong type of ETag cache is implemented through persistence.
First, create a picture:
After a brief introduction, we can implement the so-called "conditional request ".
We need to use NuGet to install CacheCow, open the NuGet console, and enter"Install-Package CacheCow. Server-Version 0.4.12". Two dll files, CacheCow. Server and CacheCow. Common, are installed.
Configuring CacheCow is also very simple. What we need to do is to create a Cache Handler and inject it into the request pipeline of the web api. This handler checks ETag and generates ETag when the request arrives and leaves the web api.
To achieve this, configure WebApiConfig. cs as follows:
cacheCowCacheHandler =
So far, our web api has implemented the cache function using the local memory, which is also the default configuration of CacheCow, In the standalone status (only one server) it is perfect. However, when applications go distributed, this is the case-because different web servers need to share the cache status, therefore, we need to make the cache state persistent to a separate place (SQL Server, MongoDB, MemCache ). However, before implementing persistence, we should first test the memory cache.
Open our test client PostMan (chrome plug-in) and send the Get request:Http: // localhost: {your_port}/api/courses/4
Caching in SQL Server is also very easy. First, we need to determine which persistent medium to implement caching. We use SQL Server. Therefore, open the NuGet console and enter the following command:Install-Package CacheCow. Server. EntityTagStore. SqlServer-Version 0.4.11.
Then, configure WebApiConfig as follows:
connString = System.Configuration.ConfigurationManager.ConnectionStrings[ eTagStore = cacheCowCacheHandler = =
The above implementation is obvious. CacheCow needs to store the cache information in the database, so we need to develop the database used by our api. Then, assign the eTagStore instance to the Cache handler.
If you directly request the api, the error code 500 is not a resource but a error code. This is because we have introduced that CacheCow needs to store the cache information to the database, so there should be a corresponding table in the database and the Stored Procedure for operating this table. Therefore, we need to execute an SQL script. This script is usually used in "{projectpath} \ packages \ CacheCow. Server. EntityTagStore. SqlServer.0.4.11 \ script"
After executing this script, you will find that the database has one more table and five stored procedures:
The last article dragged on for a long time finally met everyone. It was mainly about some theories and five lines of code. However, ETag was really powerful.
This series will come to an end here, but I will introduce some other content later (including the new features of Web Api 2, IHttpActionResult, CORS support, and OData support ), coming soon...
Source Code address: https://github.com/fzrain/WebApi.eLearning