Caching keeps reusable data or responses so later requests can avoid retrieving or computing them again. For a web API, that can reduce latency, database work, CPU use, and bandwidth. The first decision is what to cache: frequently requested GET responses may suit HTTP response caching, while repeated database queries may benefit from an application-level cache. section 8.0 section 8.1
Choose where the cached item should live:
- Client-side and intermediate caches reuse HTTP responses in browsers, reverse proxies, or CDNs. Response headers tell them whether reuse is allowed and for how long. section 3.1.3
- Server-side response caching stores eligible HTTP responses in the application, avoiding another execution of the endpoint. section 8.2.4
- In-memory caching stores arbitrary key–value data on one server. Distributed caching instead uses storage accessible to multiple web servers. section 8.3 section 8.6
For HTTP responses, mark cacheable and noncacheable endpoints explicitly. In ASP.NET Core, [ResponseCache(Location = ResponseCacheLocation.Any, Duration = 60)] sets caching directives for a response that may be reused for 60 seconds; [ResponseCache(NoStore = true)] marks a response that must not be stored. The attribute sets headers for clients and intermediaries; it does not, by itself, make the application store responses. A default no-cache, no-store directive can protect endpoints where the attribute was accidentally omitted. section 8.2 section 8.2.2
[ResponseCache(Location = ResponseCacheLocation.Any, Duration = 60)]
This attribute shows the compact ASP.NET Core configuration for a response cacheable for 60 seconds. section 8.2
To cache eligible responses on the API server too, register AddResponseCaching() and place UseResponseCaching() in the request pipeline. The middleware follows response caching directives and caches only GET or HEAD responses with a 200 OK status. Because it runs on the application server, consider its overhead against using a separate proxy or CDN. HTTP caching also honors request headers: a browser reload can bypass it, so it cannot guarantee that repeated requests avoid endpoint work. section 8.2.4 section 8.2.5
Cache a board-game query
Register AddMemoryCache(), then inject IMemoryCache into the controller. For a board-game GET request, build a key from the request type and its JSON-serialized parameters; different filters or other parameters must not share the wrong result. TryGetValue checks for a matching board-game array. On a miss, query with EF Core and store the result with a 30-second absolute expiration. To verify the behavior, set breakpoints around the lookup and database query, then repeat the same request within the expiration period. The separate record count still comes from the database unless it is cached too. section 8.3.1 section 8.3.3 section 8.5.4
Aim to cache at the highest level that fits the expected requests, but balance the mechanisms. In-memory caching gives the application control independent of browser reload headers and works well on one server; across multiple servers, separate local caches can become inconsistent, making distributed caching a useful alternative. Caching also differs by API design: GraphQL’s single endpoint and highly customized results make an efficient response cache harder to arrange than HTTP caching for REST endpoints. section 8.6 section 10.2.2
