REST List API Read
Caching
Table requests can be cached inside of the application server. This feature has been designed to improve the performance in situations in which you want to fetch not all entity items of a certain report/search at once, but in a paged manner. Without the caching the application server would re-execute the report/search every time you request the next page - which is a tremendous overhead.
Use Caching with Paging
When you intend to use the paging functionality with the startIndex and pageSize parameters, it's a good idea to also use the table caching functionality. Otherwise, the full table will be requested on server side every time you request the next page. This would lead to a big overhead and will slow down the client application, and, probably also the Product 360 server.
To use the caching you need to provide a cache id. This is an arbitrary alphanumeric string which you can define however you like. It's main purpose is to distinguish the request for a specific table from one client to the other. If you have multiple client connections which are able to share the same table, you can also define the same cacheId. It's up to the configuration of the caching in the application server how many tables and for how long they are stored in memory.
From a service API standpoint, it doesn't matter. The caching functionality is transparent to the caller. This means, in case the table has been purged from the cache in between two calls from the client, the table will be reloaded transparently.
Disable Caching
If you specify cacheId=no-cache, the caching functionality is disabled for this call, and the table will not be cached. Is is strongly recommended to provide no-cache every time you do not intend to reuse the table!
Please note that in version 1 of the Service API the default behavior of the cacheId parameter is not optimal. In fact, if you omit the cacheId, the table will be added to the cache and an arbitrary cacheId will be returned from the server.
In future versions of the Service API this behavior will be changed so that omitting the cacheId will not add the table to the cache.
Therefor we strongly recommend to always use cacheId=no-cache unless you really need the table cache. Otherwise a serious memory issue might be imposed on the application server, depending on how the list model cache is actually configured. (By default it's set to 1000 list models, eternal in memory lifetime!)