Caching
Caching in CAP can mean HTTP response validation, retaining the result of a query or function, or querying a replicated copy of service data. The core, application plugins and a backing store answer different parts of that concern. HTTP response caching, query-result caching, remote-service response caching and application-level memoisation are different choices; stale-data behaviour and tenant isolation need to be considered for the chosen layer.
Showing artifacts, examples and content with confirmed Java applicability. View All CAP
Overview
No SAP artifact is confirmed here for Java.
A Java coverage assessment has not been written. View all flavors
No community artifact is confirmed here for Java.
A Java coverage assessment has not been written. View all flavors
Artifacts
Tasks
Skip resending a record the client already has
A client that re-reads an entity it has already fetched gets 304 and no body back when the record has not changed since.
Covers a conditional read over HTTP on a served entity. Retaining a query, request or function result inside the application is a separate task, and so is telling a client how long it may reuse what it has without asking again.
Tell a client how long a served file stays fresh
A client that has fetched a file served by the application keeps using it for a stated number of seconds without asking the application again.
Covers the freshness window the application sends with a response. Answering a conditional request with 304, which still costs a round trip, is a separate task, and so is retaining a result inside the application.
Details
Coverage
Comparison properties
These are the questions used to compare what the artifacts do. Values come from their documentation and may apply to a particular ecosystem or runtime. Each recorded value in the comparison opens its statement and sources.
For your agent
- Ref
capability:caching- JSON
- /capabilities/caching.json
- MCP
- Connecting an agent