This page applies to Apigee and Apigee hybrid.
View
Apigee Edge documentation.
Apigee persistence features include caches, key value maps, and property sets. If you are using Apigee hybrid, you can use Kubernetes secrets to persist sensitive data.
| Feature | Use |
|---|---|
| Caches | Using policies for general purpose caching, you can persist any objects your proxy
requires across multiple request/response sessions. You can also cache the response of a
backend resource with the
ResponseCache policy. Response caching is especially helpful when backend
data is updated only periodically. The ResponseCache policy can reduce calls to backend
data sources. |
| Key value maps | Key value maps (KVMs) provide a general runtime store for data that may change periodically. For example: user session data, shopping cart, etc. KVM entries can be encrypted. |
| Property sets | Property sets are good for storing configuration data that doesn't change often. |
| Kubernetes secrets | (Apigee hybrid only) Use Secrets to store sensitive data such as user credentials. |
Caching
Environment-scoped cache resources are created dynamically when a cache policy executes within an API proxy flow. Cache policies include the PopulateCache policy, LookupCache policy, InvalidateCache policy, and ResponseCache policy.
A cached item stays in memory (L1) for one second. You cannot change this configuration. After one second, the cached object is placed in a database (L2) where it is available until the cache expires. For details, see In-memory persistent cache levels. You manage cache details, such as expiry time, through configuration of a cache policy. An Apigee API is provided that allows you to list and delete cache resources.
When using cache policies, you ensure the uniqueness of cached value keys by configuring cache keys. A cache key, along with other values you can configure, gives you a reliable way to get out the same data that you put in. Cache size and availability is subject to certain limits.
You might want to use a cache to:
- Reduce latency and traffic. Requests are satisfied in a shorter time and with reused representations.
- Persist data across transactions. You can store session data for reuse across HTTP transactions.
- Support security. Scope access to cache entries so they can be accessed only in a particular environment or by a specific API proxy.
Backend response caching
You can cache the response of a backend resource with the
ResponseCache policy.
This is especially helpful when backend data is updated only periodically. The ResponseCache
policy can reduce calls to backend data sources.
Through the ResponseCache policy, you can also have Apigee look at certain HTTP response caching
headers and take actions according to header directives. For example, on responses from backend
targets, Apigee supports the Cache-Control header. This header can be used to control
the maximum age of a cached response, among other things. For more information, see
Support for HTTP response headers.
Short-term general purpose caching
Using policies for general purpose caching, you can persist any objects your proxy requires across multiple request/response sessions.
With the PopulateCache
policy, LookupCache
policy, and InvalidateCache policy,
you can populate, retrieve, and flush cached data at runtime.
For example, you might temporarily store:
- Session IDs for session management.
- Credentials for outbound calls (such as API keys or OAuth access tokens).
- Response content that must be paginated for apps.
At runtime, your cache policies copy values between proxy variables and the configured cache you specify. When a value is placed in the cache, it is copied from the variable you specify to the cache. When it is retrieved from the cache, it is copied into the variable for use by your proxy.
For an example with code, see Example: General purpose caching.
Managing cache with the Apigee API
You can list and delete caches using the caches API.
Long-term persistence with key value maps (KVMs)
To indefinitely store structured data either encrypted or unencrypted, you can create and populate key value maps (KVMs) that contain arbitrary key/value pairs. For example, you might store:
- A map correlating IP addresses to country codes.
- A list of IP addresses that are allowed/denied access.
- A map correlating long URLs to shortened URLs.
- Environment-specific data, such as quota counts and OAuth token expiration times.
KVMs can have one of three scopes: organization, environment, apiproxy. For example, if key/value pairs are to be used for all APIs in an organization, create a KVM at the organization scope; or if only a specific API proxy should have access to keys/values, create the KVM at the apiproxy scope. For more information, see Working with key value maps.
Property sets
A property set is a custom collection of key/value pairs that store data. API proxies can retrieve this data when they execute.
Typically, you use property sets to store non-expiring data that shouldn't be hard-coded in your API proxy logic, such as configuration data. You can access property set data anywhere in a proxy where you can access flow variables.
A common use case for property sets is to provide values that are associated with one environment or another. For example, you can create an environment-scoped property set with configuration values that are specific to proxies running in your test environment, and another set for your production environment.
For more information, see Using property sets.
Kubernetes secrets
(Apigee hybrid only) If you are already using Kubernetes for secret management in a custom vault for sensitive data, you might want to consider using Kubernetes Secrets. Just like with KVM data, you can access the Kubernetes secret data in API proxy flow variables. For more information, see Storing data in a Kubernetes secret.