Send Docs Feedback

Policy support for persistence

You can persist data across API requests and responses (which are stateless) as well as improve improve proxy performance. Apigee Edge provides support for short- and long-term persistence through persistence policies.

For example, with the policies introduced here, you can:

  • Serve duplicates of stored static response messages from an HTTP/1.1-compliant cache.
  • Persist arbitrary objects with a general purpose caching mechanism.
  • Store simple data sets as key/value pairs with a NoSQL store.

API response persistence with a cache

You can cache API response data with the response cache using the Response Cache 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 Edge look at certain HTTP response caching headers and take actions according to header directives. For example, on responses from backend targets, Edge 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.

To optimize performance, cached responses larger than 256 KB are not distributed across the Apigee Edge server infrastructure. It's possible that a cached response will not be retrieved if it is cached on one server, but the request is handled by a different distributed server. In this case, you may see API calls that are sent to the backend even though they have been cached.

Short-term general purpose persistence with a cache

Using policies for general purpose caching, you can persist any objects your proxy requires across multiple request/response sessions.

With Populate Cache policy, LookupCache policy, and InvalidateCache policy, you can populate, retrieve, and flush cached data at runtime.

Cache entries are persisted in memory in keeping with the underlying cache's ExpirySettings (also known as "Expiration Type") value. For more about configuring cache expiration, see Creating and editing an environment cache or cache-related web services.

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 more about using general purpose cache policies, see Example: General purpose caching.

General purpose caching with the Populate Cache policy, LookupCache policy, and InvalidateCache policy uses either a cache you configure or a shared cache that's included by default. To use the underlying shared cache, simply omit the <CacheResource> element when configuring the policy.

For more about configuring caches, see Creating and editing an environment cache.

Long-term key/value persistence

To indefinitely store long-lived, structured data, you can use the Key Value Map Operations policy. Through this policy, you can store data that remains until you explicitly remove it.

For example, you might store:

  • A map correlating IP addresses to country codes.
  • A list of IP addresses for whitelisting/blacklisting.
  • A map correlating long URLs to shortened URLs.

You can manage contents of the key/value store with the following RESTful APIs: API Proxy Key/Value Maps, Env Key/Value Maps, and Org Key/Value Maps. For example, with these APIs you can perform bulk operations to populate the key/value store with large data sets.

Key/value maps work better for single entities that have many properties. For example:

curl -H "Content-Type:application/json" -X POST -d \
  "entry" : [ {
    "name" : "development",
    "value" : ""
  }, {
    "name" : "production",
    "value" : "" } ],
  "name" : "URLs"
}' \{org_name}/keyvaluemaps \
-u myname:mypass 

The result is a key/value map that can be retrieved as JSON or XML for use at runtime by policies or code that you write.

You can add entries to the key/value map by using the PUT verb. You only need to include the entries to be added:

curl -H "Content-Type:application/json" -X PUT -d \
  "entry" : [ {
    "name" : "staging",
    "value" : ""
  } ],
  "name" : "URLs"
}' \{org_name}/keyvaluemaps \
-u myname:mypass 

Help or comments?