This blog promotes knowledge sharing through experience and collaboration. For more product information, visit our WebSphere Commerce CSE page. For easier navigation, utilize the Categories to find posts that match your interest.
REST Caching in WebSphere Commerce
WebSphere Commerce uses REST services to provide a framework to develop RESTful applications. REST services use both server-side caching and client-side caching. Server-side caching is achieved by using dynacache, and client-side caching is achieved by using cache directives in the response header. Although REST service caching is well-documented in IBM Knowledge Center (see Representational State Transfer (REST) services, Caching strategies for REST services), in this blog post, I will give you a quick summary of how caching can be applied in REST.
REST calls to Commerce
If you have an external application making REST calls to WebSphere Commerce, for example, issuing this REST call "/wcs/resources/store/storeID/productview/byId/productId", you can enable caching using the sample samples/dynacache/REST/cachespec.xml in Rest.war. The sample cachespec.xml is pre-configured to support caching for all the OOTB provided services. You might need to adjust the dependency ids so they match the ones used in the store (if they don't match Aurora).
The framework also has a feature to allow you control client side caching by setting the Expires and Cache-Control headers. See wc-rest-clientCaching.xml under the Client Side Caching strategies for REST services for details.
REST calls from Commerce to Search
There are multiple caching options to support a RESTified store. You can look into caching REST calls to Search after implementing "standard" JSP/Servlet caching for the store front. You can cache the REST response in both Commerce server and Search server.
The easiest way to extend caching is by enabling caching of the REST responses to Search in WC. Responses are cached in the WCRESTTagDistributedMapCache distributed map when the REST call is done when the wcf:rest tag with the cached=true attribute inside a jsp.
Enabling caching on other calls is straightforward (just add cached=true) and you don't need to change the cachespec.xml. The drawback of this approach is that it doesn't provide fine tuning of invalidations. Cache entries have a 1-hour timeout by default. You can change it by adding a <WCRESTTagDistributedMapCache> in the wc-server.xml and specify the Timeout value (See Additional data cache configuration). To remove entries earlier than that, you will need to empty the whole cache or this particular cache instance.
In addition, you can cache REST response in the baseCache from the Search server side, using the Search-Rest/cachespec.xml sample in Search-Rest.war. This approach is similar to enabling REST caching on the WC server for external requests.For example, if you issue this REST call to search: "/search/resources/store/10001/categoryview/@top", you should be able to see below cache entry in the cache monitor.
To get more details, you can refer to this blog post written by Marco Fabbri, Activate baseCache on Search Server for REST calls.
Data Cache has now also been made available in the Search JVMs since Feature Pack 7. Data Cache is being used in both Commerce and Search servers through the life-cycle of the executions. You can learn about how data cache is used in Search server by reading this excellent blog written by Andres here The Data Cache Moves to the Search Server.
In summary, if you are looking at improving performance with caching, start by implementing the traditional full page Dynacache servlet caching (if you are running a storefront), and then look into the REST caching options described in this post to get an additional performance boost.