Mise en cache des paramètres DBX

De RAD Studio
Aller à : navigation, rechercher

Remonter à DataSnap REST


La mise en cache des paramètres DBX dans les sessions REST permet l'exécution d'une méthode serveur avec plusieurs paramètres de sortie ou de retour, sans la nécessité de renvoyer les résultats de type complexe, tels que les tables, les objets, et ainsi de suite, formatés en JSON. Pour que cela soit possible, la mise en cache des types complexes sur le serveur est introduite. En outre, une URL (Uniform Resource Locator) est fournie au client pour qu'il accède à chacun des types de retour, individuellement.

Autres détails

Prenez comme exemple cette méthode sur le serveur :

function GetImage(Name: String; out Stream: TStream): TStream;

Notez que la fonction GetImage renvoie deux flux. Avant l'introduction de la mise en cache des paramètres, la seule option pour l'exécution de cette méthode serveur était par le biais d'une URL de ce type : http://host:port/datasnap/rest/Classame/GetImage/Name.

Cette URL exécute la fonction correctement, mais les deux flux sont renvoyés comme des tableaux JSON d'octets. Quand un seul flux est renvoyé, vous êtes capable de contrôler le format de sortie avec le paramètre URL json (true/false). Toutefois, cela est ignoré si plusieurs résultats sont renvoyés, afin d'éviter une perte de données.

Vous êtes maintenant capable d'exécuter cette même fonction (par exemple, GetImage) avec l'URL donnée ci-dessus, en passant application/rest en tant que valeur d'en-tête Accept de la requête. De cette façon, le serveur sait que vous voulez utiliser le cache de la session en cours pour gérer les paramètres complexes. C'est la façon dont sont résolus les problèmes de pertes de données, mais l'utilisateur doit atteindre le serveur une fois pour l'appel de la méthode, et une autre fois pour chaque paramètre complexe qu'il veut lire.

Un exemple

Le code suivant est un exemple qui exécute la fonction exemple GetImage. Il est supposé dans cet exemple que les deux flux sont des images. L'exemple remplit une page web, contenant deux images, avec les images en cache.


  function PopulateImages()
  {
    var exec=new ServerFunctionExecutor("ClassName");
    var resultObj=exec.executeMethod("GetImage", null, "GET", ["Key"], null, true, null, "application/rest");
    // returns: {"result":["0/0/0", "0/0/1"],"cacheId":0,"cmdIndex":0}
    document.getElementById("image1").src=exec.getCacheURL(resultObj.result[0],true);
    document.getElementById("image2").src=exec.getCacheURL(resultObj.result[1],true);
  }


Le code présenté ci-dessus fait plusieurs hypothèses sur la page web avec laquelle il est chargé, mais il devrait illustrer l'idée de base. Deux modifications majeures au ServerFunctionExecutor sont visibles. Premièrement, la fonction executeMethod prend un paramètre facultatif à la fin, qui sera la valeur utilisée dans l'en-tête Accept de la requête. Deuxièmement, une nouvelle fonction appelée getCacheURL a été ajoutée. Elle renvoie l'URL complète à l'objet en cache, basée sur l'URL partielle URL fournie dans le résultat de l'exécution. La valeur true passée en second paramètre indique d'ajouter l'ID de session à l'URL renvoyée, afin que l'URL puisse travailler de façon autonome, sans le ServerFunctionExecutor.

Format du résultat

Le code présenté ci-dessus fait plusieurs hypothèses sur la page web avec laquelle il est chargé, mais il devrait illustrer l'idée de base. Deux modifications majeures au ServerFunctionExecutor sont visibles. Premièrement, la fonction executeMethod prend un paramètre facultatif à la fin, qui sera la valeur utilisée dans l'en-tête Accept de la requête. Deuxièmement, une nouvelle fonction appelée getCacheURL a été ajoutée. Elle renvoie l'URL complète à l'objet en cache, basée sur l'URL partielle URL fournie dans le résultat de l'exécution. La valeur true passée en second paramètre indique d'ajouter l'ID de session à l'URL renvoyée, afin que l'URL puisse travailler de façon autonome, sans le ServerFunctionExecutor.

Comme mentionné ci-dessus, lors de la spécification de application/rest en tant que type Accept, le résultat que vous obtiendrez en retour sera légèrement différent. La principale différence est que, pour chacun des types de données complexes tels que Table, Objet, Flux, et ainsi de suite, le résultat que vous obtiendrez en retour est un fragment d'URL au lieu de la valeur réelle. Le fragment peut être défini comme suit :

[ID d'élément de cache]/[Index de commande]/[Index de paramètre]

ID d'élément de cache est l'identificateur unique de l'invocation de méthode exécutée. Toutefois, notez que seules les exécutions qui stockent des résultats dans le cache obtiennent des identificateurs uniques. Index de commande identifie la commande de l'exécution à laquelle le résultat se réfère. C'est une valeur différente de zéro seulement si vous avez effectué une exécution par lots impliquant plusieurs méthodes serveurs à la fois. Index de paramètre est l'index du paramètre complexe à renvoyer. C'est un index de base zéro, et il est basé seulement sur les paramètres complexes de la commande, à l'exclusion des autres.

Interaction avec le cache

A part cette différence, notez que l'objet résultat a deux nouvelles propriétés, CacheId et CmdIndex. Ces propriétés sont les mêmes valeurs que les deux premières parties du fragment d'URL mentionné ci-dessus, et existent seulement afin que leurs valeurs puissent être récupérées sans analyse du fragment d'URL.

Les URLs de cache supportent les types de requêtes GET et DELETE.

URL Signification

http://host:port/datasnap/cache

Renvoie un objet JSON décrivant le contenu du cache.

http://host:port/datasnap/cache/[CacheID]

Renvoie un objet JSON décrivant l'objet de cache avec l'ID donné.

http://host:port/datasnap/cache/[CacheID]/[CmdIndex]/

Renvoie une représentation JSON de la commande donnée.

http://host:port/datasnap/cache/[CacheId]/[CmdIndex]/[ParameterIndex]

Renvoie le paramètre réel, en tant que JSON ou flux.

Lors de l'émission d'une commande GET, les URLs suivantes sont disponibles :

URL Signification

http://host:port/datasnap/cache

Supprime tous les éléments en cache.

http://host:port/datasnap/cache/[CacheID]

Supprime les éléments en cache et toutes ses commandes et/ou paramètres.

Filtres de requêtes

Lors de l'émission d'une commande DELETE, les URLs suivantes sont supportées :

  • L'appel initial à la méthode serveur ignorera tout filtre de requête sur les types complexes. Les filtres pour ces paramètres ne seront pas appliqués sur les types complexes, ni mémorisés pour un usage ultérieur lors de la récupération des paramètres depuis le cache.
  • Lors de l'utilisation de filtres de requêtes sur un flux en cache, vous devez ajouter le paramètre json=false. Sinon, les filtres seront ignorés et le flux sera renvoyé directement en tant que flux de contenu de la réponse.
  • L'index de paramètre pour le filtre est l'index de paramètre original, et pas l'index du paramètre complexe dans le cache. En d'autres termes, l'index est le même que ce que vous auriez spécifié si vous aviez utilisé le filtre dans l'invocation de méthode originale.

Modifications de proxy JS

Quand vous n'utilisez pas le cache, les filtres de requêtes fonctionnent de la façon habituelle. Lors de l'utilisation du cache, une requête GET qui spécifie un paramètre particulier (par exemple, CacheId/CmdIndex/ParameterIndex) supporte les mêmes filtres de requêtes. Néanmoins, plusieurs choses sont à noter lors de leur utilisation :

Voir aussi