Caching strategies for REST services

The following diagram shows the REST cache framework interactions flow:

Where:

1. RESTCacheFilter parses the request URI, tokenize it, and adds it to the attribute. It also gets the other attributes, such as previewToken, from the HTTP header.

   The path token is taken from the URL and set to the attribute with the servlet cache filter.

2. The cache-id in the cachespec.xml file defines the rule for caching the REST request. The cache entry of a specific resource is generated with the cache-id.
3. The dependency-id in in the cachespec.xml specifies the additional cache identifiers and associates them with existing dependency-id types.
4. If the identifier-id needs to be converted, RESTMetaDataGenerator generates the dependency-id with an ID.
5. If the cache-id exists in the DynaCache instance, it returns the cache entry directly from the cache. If the cache-id does not exist in the DynaCache instance, it calls the backend servlet to create the cache entry and returns the data to the requester.

To generate dependencies on the HCL Commerce server:

1. Define the dependency-id for identifier, such as CategoryDisplay:storeId:categoryIdentifier, and find the existing related dependency-id, such as CategoryDisplay:storeId:categoryIdentifier. This ensures that the current invalidation function can invalidate the cache entry.
2. In RESTMetaDataGenerator, it gets the current cache entry-related dependency-id when the request is received.
3. In RESTMetaDataGenerator, it sends the query to the backend system to get the ID of the item with the identifier as a query parameter, such as storeId, and categoryIdentifier. To improve the performance of queries, it can use the local data cache to cache the query.
4. In RESTMetaDataGenerator, set the ID as the dependency-id such as CategoryDisplay:storeId:categoryId.

For example, to convert the dependency-id in RESTMetaDataGenerator:

Enumeration dataIds = fragmentInfo.getDataIds();
    while(dataIds.hasMoreElements()){
         String dataId = (String)dataIds.nextElement();
         String covertedDataId = convertDataId(dataId, req);

        if(covertedDataId!=null){
       fragmentInfo.addDataId(covertedDataId);
    }
}

Server-side caching is achieved by using dynacache. You can customize the provided sample file cachespec.xml as required, by providing custom rules for caching and invalidation, and generating dependencies between them. The sample cachespec.xml file can be found at the following location:

Transaction server REST API

WCDE_installdir\components\foundation\samples\dynacache\REST

The com.ibm.commerce.rest.caching.RESTCacheFilter extracts the path parameters and sets it as request attributes. The request attributes are then used to build cache-ids. The cache-id rules are then applied to determine which of the following URLs are cacheable:

• /wcs/resources/store/storeID/categoryview/@top
• /wcs/resources/store/storeID/categoryview/categoryIdentifier
• /wcs/resources/store/storeID/categoryview/byId/categoryId
• /wcs/resources/store/storeID/categoryview/byIds
• /wcs/resources/store/storeID/categoryview/byParentCategory/parentCategoryId
• /wcs/resources/store/storeID/productview/partnumber
• /wcs/resources/store/storeID/productview/byId/productId
• /wcs/resources/store/storeID/productview/byCategory/categoryId
• /wcs/resources/store/storeID/productview/bySearchTerm/searchTerm
• /wcs/resources/store/storeID/espot/espotIdentifier
• /wcs/resources/store/storeID/espot/espotIdentifier/category/categoryID
• /wcs/resources/store/storeID/espot/espotIdentifier/product/productID

RESTCacheFilter sets the following request attributes:

The dependency-ids are generated to match the invalidation scheme that is defined in other sample cachespec.xml files.

Client-side caching is achieved by using cache directives in the response header. The directives that can be set in the response headers are:

• Expires
• Cache-Control

The Cache-Control directive supports only whether the resource is private or publicly cacheable.

The REST services web module configures the following resources in the WEB-INF/config/com.ibm.commerce.rest/wc-rest-clientCaching.xml file:

<cache>
  <!-- resource name="example" expiresAfter="60 (mins)" isPrivate="true|false"-->

  <resource name="categoryview" expiresAfter="60" isPrivate="false"/>
  <resource name="productview" expiresAfter="60" isPrivate="false"/>
  <resource name="espot" expiresAfter="60" isPrivate="false"/>
</cache>

The following conditions are required:

1. Client-side caching is enabled for the REST service. To set up client-side caching, see the previous section.
2. The cached="true" attribute must be specified. For example:

   
   <wcf:rest var="sdb" url="store/{storeId}/databean" cached="true">
   <wcf:var name="storeId" value="${storeId}" encode="true"/>
   <wcf:param name="profileName" value="IBM_Store_Details" encode="true"/>
   <wcf:param name="langId" value="${langId}" encode="true"/>
   <wcf:param name="jspStoreDir" value="${jspStoreDir}" encode="true" />
   </wcf:rest>
   

Response of REST requests based on the preceding URL and parameters are cached inside the data cache that is called RESTTagCache, with the services/cache/WCRESTTagDistributedMapCache cache JNDI name. This caching is applicable to REST services provided by both HCL Commerce and HCL Commerce search servers.