Stratégies de mise en cache pour les services REST

Les services REST utilisent à la fois la mise en cache côté serveur et la mise en cache côté client. La mise en cache côté serveur est obtenue à l'aide de la mise en cache dynamique, et la mise en cache côté client est réalisée à l'aide de directives de cache dans l'en-tête de réponse.

Structure du cache REST

Le diagramme suivant montre le flux d'interactions de la structure de cache REST :

Où :

RESTCacheFilter analyse l'URI de la requête, la segmente et l'ajoute à l'attribut. Il obtient également les autres attributs, tels que previewToken, à partir de l'en-tête HTTP.
Le jeton du chemin d'accès issu de l'URL et défini sur l'attribut avec le filtre de cache du servlet.
L'ID cache-id dans le fichier cachespec.xml définit la règle de mise en cache de la requête REST. L'entrée de cache d'une ressource spécifique est générée avec l'ID cache-id.
L'ID dependency-id in dans le fichier cachespec.xml spécifie les identificateurs de cache supplémentaires et les associe à des types dependency-id existants.
Si l'ID identifier-id doit être converti, RESTMetaDataGenerator génère l'ID dependency-id avec un ID.
Si l'ID cache-id existe dans DynaCache, il renvoie l'entrée du cache directement à partir du cache. Si l'ID cache-id n'existe pas dans l'instance DynaCache, il appelle le servlet d'arrière-plan pour créer l'entrée de cache et renvoie les données au demandeur.

Pour générer des dépendances sur le serveur HCL Commerce :

Définissez l'ID dependency-id pour l'identificateur, tel que CategoryDisplay:storeId:categoryIdentifier, et recherchez les produits existants, tels que dependency-id et CategoryDisplay:storeId:categoryIdentifier. Cela garantit que la fonction d'invalidation actuelle peut invalider l'entrée du cache.
Dans RESTMetaDataGenerator, il obtient l'ID dependency-id lié à l'entrée de cache actuelle lorsque la requête est reçue.
Dans RESTMetaDataGenerator, il envoie la requête au système d'arrière-plan pour obtenir l'ID de l'article avec l'identificateur comme paramètre de requête, tel que storeId et categoryIdentifier. Pour améliorer les performances des requêtes, il peut utiliser le cache de données local pour mettre en cache la requête.
Dans RESTMetaDataGenerator, définissez l'ID en tant qu'ID dependency-id, tel que CategoryDisplay:storeId:categoryId.

Par exemple, pour convertir l'ID dependency-id dans RESTMetaDataGenerator :


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

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

La génération de dépendances sur le serveur HCL Commerce Search n'est pas prise en charge, car il n'y a pas de générateur de métadonnées par défaut pour le mappage de partNumber et categoryIdentifier à leur ID de produit ou à leur ID de catégorie correspondant.

La classe com.ibm.commerce.rest.caching.RESTKeyListMetaDataGenerator peut diviser plusieurs ID dans les requêtes de demande REST en plusieurs ID de dépendance pour chaque ID individuel. Cette classe peut être utilisée à la fois sur les serveurs HCL Commerce et HCL Commerce Search.

Mise en cache côté serveur

La mise en cache côté serveur est réalisée à l'aide de dynacache. Vous pouvez personnaliser l'exemple de fichier cachespec.xml fourni en fonction des besoins, en fournissant des règles personnalisées pour la mise en cache et l'invalidation, et en générant des dépendances entre elles. L'exemple de fichier cachespec.xml est disponible à l'emplacement suivant :

Transaction server API REST: WCDE_installdir\components\foundation\samples\dynacache\REST

com.ibm.commerce.rest.caching.RESTCacheFilter extraits des paramètres de chemin d'accès et le définit comme attributs de requête. Les attributs de requête sont ensuite utilisés pour générer des ID de cache. Les règles d'ID de cache sont ensuite appliquées pour déterminer lesquelles des URL suivantes peuvent être mises en cache :

/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

API REST de recherche Solr

Le conteneur du serveur Solr inclut un exemple de fichier cachespec.xml qui contient des configurations de mise en cache REST. Le conteneur du serveur Solr inclut l'exemple de fichier cachespec.xml.sample à l'emplacement suivant : /profile/apps/search-ear.ear/search-rest.war/WEB-INF/cachespec.xml.rest.sample.

Implémentez la mise en cache étendue en fusionnant les règles de mise en cache dans le search-rest.war/WEB-INF/cachespec.xml.rest.sample à l'emplacement /profile/apps/search-ear.ear/search-rest.war/WEB-INF/cachespec.xml.

com.ibm.commerce.rest.caching.RESTCacheFilter extrait des paramètres de chemin d'accès et le définit comme attributs de requête. Les attributs de requête sont ensuite utilisés pour générer des ID de cache. Les règles d'ID de cache sont ensuite appliquées pour déterminer lesquelles des URL suivantes peuvent être mises en cache :

/search/resources/store/{storeId}/categoryview/@top
/search/resources/store/{storeId}/categoryview/{categoryIdentifier}
/search/resources/store/{storeId}/categoryview/byId/{uniqueID}
/search/resources/store/{storeId}/categoryview/byIds?id={uniqueID1}&id={uniqueID2}
/search/resources/store/{storeId}/categoryview/byParentCategory/{category_unique_id}
/search/resources/store/{storeId}/productview/{partnumber}
/search/resources/store/{storeId}/productview/byPartNumbers?partNumber={partnumber1}&partNumber={partnumber2}
/search/resources/store/{storeId}/productview/byId/{uniqueID}
/search/resources/store/{storeId}/productview/byIds?id={uniqueID1}&id={uniqueID2}
/search/resources/store/{storeId}/productview/byCategory/{category_unique_id
/search/resources/store/{storeId}/productview/bySearchTerm/{searchTerm}?pageNumber={pageNumber}&pageSize={pageSize}
/search/resources/store/{storeId}/productview/bySearchTerm/{searchTerm}?metaData={metaDataValue}
/search/resources/store/{storeId}/sitecontent/webContentsBySearchTerm/{searchTerm}
/search/resources/store/{storeId}/sitecontent/suggestions

RESTCacheFilter définit ensuite les attributs de requête suivants :

Les attributs de requête et les paramètres de chemin d'accès dans les URL REST
Attribut de requête	Paramètre de chemin d'accès dans l'URL REST
storeId	`storeID`
catalogId	`catalogID`
ID_produit	L'ID de produit des valeurs `partnumber`, `productID` et `uniqueID` de l'URL du produit
categoryId	L'ID de catégorie de l'URL de catégorie `groupID`, `categoryID`, `category_unique_ID` et `uniqueID`
espotId	`espotIdentifier`
searchTerms	`searchTerm`
action	Valeur acceptées : topCategories productDisplay categoryDisplay
urlType	Valeur acceptées : espot search Remarque : L'attribut de requête urlType n'est pas utilisé.

Les ID de dépendance sont générés pour correspondre au schéma d'invalidation défini dans d'autres exemples de fichier cachespec.xml.

Remarque : Vérifiez les fichiers cachespec.xml sous les répertoires d'invalidation/de magasin et d'invalidation/de catalogue pour obtenir des définitions plus détaillées.

La mise en cache côté serveur pour les services REST fournis par le serveur HCL Commerce qui utilise le cache servlet et les fichiers JSP ne peut pas être utilisée en raison de la liaison locale sur l'application Web du magasin. Toutefois, les applications externes en dehors de l'EAR HCL Commerce peuvent utiliser la mise en cache côté serveur fournie par le serveur HCL Commerce. En revanche, les services REST fournis par le serveur de recherche peuvent être mis en cache à l'aide de la mise en cache côté serveur, car ils sont déployés en dehors du serveur HCL Commerce. Pour plus d'informations, voir Les fichiers JSP de vitrine qui utilisent la mise en cache côté client.

Mise en cache côté client

La mise en cache côté client est réalisée à l'aide de directives de cache dans l'en-tête de réponse. Les directives qui peuvent être définies dans les en-têtes de réponse sont les suivantes :

Date d'expiration
Contrôle de cache

La directive contrôle de cache assure une prise en charge uniquement si la ressource est privée ou peut être mise en cache publiquement.

Le module Web des services REST configure les ressources suivantes dans le fichier WEB-INF/config/com.ibm.commerce.rest/wc-rest-clientCaching.xml :


<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>

Les directives de mise en cache pour les ressources REST peuvent être remplacées ou ajoutées. Pour remplacer le délai d'expiration ou activer la mise en cache du client pour plus de ressources REST, créez ou modifiez un fichier WEB-INF/config/com.ibm.commerce.rest-ext/wc-rest-clientCaching.xml personnalisé.

Les fichiers JSP de vitrine qui utilisent la mise en cache côté client

Les fichiers JSP de vitrine peuvent utiliser la mise en cache côté client lorsque vous appelez les services REST à l'aide de la bibliothèque de balises <wcf:rest>.

Les conditions suivantes doivent être remplies :

La mise en cache côté client est activée pour le service REST. Pour configurer la mise en cache côté client, voir la section précédente.

L'attribut cached="true" doit être spécifié. Par exemple :


<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>

La réponse des requêtes REST basées sur l'URL et les paramètres précédents sont mis en cache à l'intérieur du cache de données appelé RESTTagCache, avec le nom JNDI de cache services/cache/WCRESTTagDistributedMapCache. Cette mise en cache s'applique aux services REST fournis par les serveurs de recherche HCL Commerce et HCL Commerce.

Important : Tout fichier JSP mis en cache ou tout fragment de fichier JSP qui utilise la balise <wcf:rest> pour démarrer les services REST doit marquer l'entrée de son cache consume-subfragments sur true dans le fichier cachespec.xml du magasin. Si ce n'est pas fait, les fichiers JSP ou les fragments de fichiers JSP mis en cache peuvent mal démarrer les services REST et provoquer des erreurs d'exécution.

Recherche Solr - Configurations de mise en cache étendues

Mise en cache REST Solr: Le conteneur Transaction server inclut un exemple de fichier cachespec.xml qui contient des configurations de mise en cache REST pour le magasin Emerald (B2C). Implémentez la mise en cache étendue en fusionnant les règles de mise en cache de /profile/apps/search-ear.ear/search-rest.war/WEB-INF/cachespec.xml.rest.sample dans le fichier search-rest.war > cachespec.xml à l'emplacement /profile/apps/search-ear.ear/search-rest.war/WEB-INF/cachespec.xml.