Project: APISIX (Orchestration & Management / API Gateway)
File: cache-api-responses.md

title: Cache API responses keywords: API Gateway Apache APISIX Cache Performance description: This tutorial will focus primarily on handling caching at the API Gateway level by using Apache APISIX API Gateway and you will learn how to use proxy-caching plugin to improve response efficiency for your Web or Microservices API. <!-- --> This tutorial will focus primarily on handling caching at the API Gateway level by using Apache APISIX API Gateway and you will learn how to use the proxy-cache plugin to improve response efficiency for your Web or Microservices API. Here is an overview of what we cover in this walkthrough: Caching in API Gateway About Run the demo project Configure the plugin Validate Proxy Caching When you are building an API, you want to keep it simple and fast. Once the concurrent need to read the same data increase, you'll face a few issues where you might be considering introducing caching: There is latency on some API requests which is noticeably affecting the user's experience. Fetching data from a database takes more time to respond. Availability of your API is threatened by the API's high throughput. There are some network failures in getting frequently accessed information from your API. ) is capable of storing and retrieving network requests and their corresponding responses. Caching happens at different levels in a web application: Edge caching or CDN Database caching Server caching (API caching) Browser caching Reverse Proxy Caching is yet another caching mechanism that is usually implemented inside API Gateway. It can reduce the number of calls made to your endpoint and also improve the latency of requests to your API by caching a response from the upstream. If the API Gateway cache has a fresh copy of the requested resource, it uses that copy to satisfy the request directly instead of making a request to the endpoint. If the cached data is not found, the request travels to the intended upstream services (backend services). With the help of Apache APISIX, you can enable API caching with plugin to cache your API endpoint's responses and enhance the performance. It can be used together with other Plugins too and currently supports disk-based caching. The data to be cached can be filtered with responseCodes, requestModes, or more complex methods using the noCache and cacheByPass attributes. You can specify cache expiration time or a memory capacity in the plugin configuration as well. Please, refer to other `proxy-cache` plugin's . With all this in mind, we'll look next at an example of using `proxy-cache` plugin offered by Apache APISIX and apply it for

Core Web API with a single endpoint. Until now, I assume that you have the demo project is up and running. You can see the complete source code on Github and the instruction on how to build a multi-container APISIX via Docker CLI. In the ASP.NET Core project, there is a simple API to get all products list from the service layer in file. Let's assume that this product list is usually updated only once a day and the endpoint receives repeated billions of requests every day to fetch the product list partially or all of them. In this scenario, using API caching technique with `proxy-cache` plugin might be really helpful. For the demo purpose, we only enable caching for `GET` method. Ideally, `GET` requests should be cacheable by default-until a special condition arises. Now let's start with adding `proxy-cache` plugin to Apache APISIX declarative configuration file `config.yaml` in the project. Because in the current project, we have not registered yet the plugin we are going to use for this demo. We appended `proxy-cache` plugin's name to the end of plugins list: ``` yaml plugins: -http-logger -ip-restriction -proxy-cache ``` You can add your cache configuration in the same file if you need to specify values like disksize, memorysize as shown below: ``` yaml proxy_cache: cache_ttl: 10s # default caching time if the upstream doesn't specify the caching time zones: -name: diskcacheone # name of the cache. Admin can specify which cache to use in the Admin API by name memory_size: 50m # size of shared memory, used to store the cache index disk_size: 1G # size of disk, used to store the cache data diskpath: "/tmp/diskcache_one" # path to store the cache data cache_levels: "1:2" # hierarchy levels of the cache ``` Next, we can directly run `apisix reload` command to reload the latest plugin code without restarting Apache APISIX. See the command to reload the newly added plugin: :::note You can fetch the `admin_key` from `config.yaml` and save to an environment variable with the following command: ```bash adminkey=$(yq '.deployment.admin.adminkey[0].key' conf/config.yaml | sed 's/"//g') ``` ::: ``` shell curl http://127.0.0.1:9180/apisix/admin/plugins/reload -H "X-API-KEY: $admin_key" -X PUT ``` Then, we run two more curl commands to configure an Upstream and Route for the `/api/products` endpoint. The following command creates a sample upstream (that's our API Server): ``` shell curl

-H "X-API-KEY: edd1c9f034335f136f87ad84b625c8f1" -X PUT -d ' { "type": "roundrobin", "nodes": { "productapi:80": 1 } }' ``` Next, we will add a new route with caching ability by setting `proxy-cache` plugin in `plugins` property and giving a reference to the upstream service by its unique id to forward requests to the API server: ``` shell curl "http://127.0.0.1:9180/apisix/admin/routes/1" -H "X-API-KEY: edd1c9f034335f136f87ad84b625c8f1" -X PUT -d '{ "name": "Route for API Caching", "methods": [ "GET" ], "uri": "/api/products", "plugins": { "proxy-cache": { "cache_key": [ "$uri", "-cache-id" ], "cache_bypass": [ "$arg_bypass" ], "cache_method": [ "GET" ], "cachehttpstatus": [ 200 ], "hidecacheheaders": true, "no_cache": [ "$arg_test" ] } }, "upstream_id": 1 }' ``` As you can see in the above configuration, we defined some plugin attributes that we want to cache only successful responses from the `GET` method of API. Finally, we can test the proxy caching if it is working as it is expected. We will send multiple requests to the `/api/products` path and we should receive `HTTP 200 OK` response each time. However, the `Apisix-Cache-Status` in the response shows MISS meaning that the response has not cached yet when the request hits the route for the first time. Now, if you make another request, you will see that you get a cached response with the caching indicator as HIT. Now we can make an initial request: ``` shell curl http://localhost:9080/api/products -i ``` The response looks like as below: ``` shell HTTP/1.1 200 OK Apisix-Cache-Status: MISS ``` When you do the next call to the service, the route responds to the request with a cached response since it has already cached in the previous request: ``` shell HTTP/1.1 200 OK Apisix-Cache-Status: HIT ``` Or if you try again to hit the endpoint after the time-to-live (TTL) period for the cache ends, you will get: ``` shell HTTP/1.1 200 OK Apisix-Cache-Status: EXPIRED ``` Excellent! We enabled caching for our API endpoint. Optionally, you can also add some delay in the Product controller code and measure response time properly with and without cache: ``` c# [HttpGet] public IActionResult GetAll() { Console.Write("The delay starts.\n"); System.Threading.Thread.Sleep(5000); Console.Write("The delay ends."); return Ok(_productsService.GetAll()); } ``` The `curl` command to check response time would be: ```shell curl -i 'http://localhost:9080/api/products' -s -o /dev/null -w "Response time: %{time_starttransfer} seconds\n" ``` As we learned, it is easy to configure and quick to set up API response caching for our ASP.NET Core WEB API with the help of Apache APISIX. It can reduce significantly the number of calls made to your endpoint and also improve the latency of requests to your API. There are other numerous built-in plugins available in Apache APISIX, you can check them on and use them per your need. You can refer to to learn about how to expose your first API. You can refer to to protect your API.