Caching of GET requests

Enabling caching

You enable caching for individual resources by creating system properties. The system properties must be in the form mxe.rest.handler.resource.cache, where handler is mbo or os and resource is the name of the business object or object structure. The system properties must have a Boolean value of 1.

For example, the system property mxe.rest.mbo.workorder.cache set to a value of 1 enables caching for the work order business object.

Entity tag calculations and comparisons

When an initial request is made for a resource and caching is enabled for the resource, the framework generates an ETag value for the resource response. The ETag is calculated based on the MBO rowstamp attribute, which changes any time an MBO is modified. For a resource collection, the ETag is calculated based on a hash of the collection of rowstamp values from the MBOs in the collection.

For example, the response contains the following in the HTTP header:

HTTP/1.1 200 OK
ETag: "123456789"
Cache-control: private
Content-Length: 12195

The Cache-control is marked as private to ensure that only the current user can reuse the contents of the cache.

When the user makes a repeat request for the same resource or collection, the request is similar to the following:

GET maxrest/rest/mbo/po HTTP/1.1
Host: x.y
If-None-Match: "123456789"

The If-None-Match value is the ETag value from the previous request. The framework reads the If-None-Match header value and compares it to the new calculated ETag value for the resource or collection for the second request. If the values match, the server responds with an HTTP 304, implying that the client cache content is valid and can be used. The response includes the following line:

HTTP/1.1 304 Not Modified

If the ETag value does not match the If-None-Match header value of the request, the resource representation is constructed and sent to the client with a new ETag value to be used by the client for subsequent requests for the resource or collection:

HTTP/1.1 200 OK
ETag: "98999999"
Cache-control: private
Content-Length: 50004

Pessimistic caching mode

The default caching mode is pessimistic caching. In pessimistic caching mode, requests are serialized but the data is not sent from the server to the client when the ETag value of the request matches the value of the previous request.

Optimistic caching mode

You can enable optimistic caching by setting the mxe.rest.handler.resource.optimistic system property to 1. In optimistic caching mode, the ETag value is calculated before any data serialization occurs. Although optimistic caching can improve response times significantly because no serialization occurs, it requires more memory, especially for queries that request many records.

By default, optimistic caching determines the ETag value from the root object of an object structure. Therefore, if an object structure has related objects that do not update the root object, the ETag value might not be accurate. You can ensure that the ETag value is determined from all the objects in the object structure, including related objects, by setting the mxe.rest.handler.resource.deepetag system property to 1. However, by using this system property, the performance improvement is not as great and more memory is used.

Cache time limits

You can configure the length of time that the cache is valid for by setting the mxe.rest.handler.resource.maxage system property to a value measured in seconds.