Introduction à LightREST

Le composant LightREST contient toutes les fonctions et constantes nécessaires pour faciliter le développement de Web Services REST sous WinDev^®.

Il met à disposition du développeur :

• Les Classes lrServer, lrRoute, lrRequest, lrResponse, lrHook, lrSession.
• Les Constantes Method : Méthodes REST (GET, POST, …)
• Les Constantes Content : Type MIME du contenu de la réponse (application/json, text/plain, …)
• Les Constantes Status : Statut d’exécution (200=OK, 401=Non autorisé, …)

Nul besoin de connaître les codes des statuts ou des types MIME par coeur, les constantes LightREST sont là pour les renseigner à votre place.

L’implémentation d’un serveur REST avec LightREST se fait simplement :

• Détermination des API à déployer : Pour chaque API, une route est définir (=une URL + une méthode). Chaque Route est rattachée à une procédure WinDev^® qui sera exécutée par LightREST lorsqu’une URL correspondant à la Route sera appelée. Pour une meilleure lisibilité, cette procédure WinDev^® sera appelée Handler dans cette documentation.
• Implémentation des Handlers REST : Pour chaque Route+Méthode, le handler reçoit un objet lrRequest en paramètre et doit retourner un résultat de type lrResponse (NB : à partir de la version 3, le handler reçoit les 2 objets en paramètres, et ne retourne plus rien).

Chaque handler REST est exécuté par LightREST avec un contexte Hyperfile séparé, il n’y a donc pas de risques de collisions lorsque plusieurs appels REST sont exécutés simultanément (un même handler peut se trouver en cours d’exécution plusieurs fois en parallèle au même instant). Il est toutefois recommandé d’ouvrir systématiquement une connexion à la base de données (que ce soit Hyperfile ou une autre) pour bien isoler les traitements du point de vue du moteur de la base de données. L’ouverture d’une connexion est rarement coûteuse en temps, et cela permet de sécuriser le système.

Si un handler doit accéder à une variable globale du projet, il est recommandé d’utiliser des Sémaphores. C’est un mécanisme simple à mettre en œuvre, et qui garantira que deux procédures REST n’accèdent pas en même temps à la même variable.

Précaution importante (quels que soient la technologie REST et le langage de programmation employés) : L’échange de données avec un client REST entraîne souvent l’envoi d’identifiant de la base de données, afin que des requêtes ultérieures puissent être réalisées.

Scénario :

• On renvoie une liste de clients avec leur IDs respectifs :
  • Jean Valjean, ID 512
  • Esmeralda, ID 234
  • Causette, ID 235
• Un service REST permet de récupérer les informations d’un client. Exemple : http://monserveur.com/client/235
• Rien n’empêche un utilisateur malin d’essayer les IDs 236, 237, 238 pour récupérer des données auxquelles il n’a probablement pas accès, voire d’essayer de les effacer.

Pour éviter ce genre de fuite des données :

• Ne jamais transmettre dans un résultat un ID automatique de la base de données. Préférer soit un chiffrement de l’identifiant (fonctions Crypte) de WinDev^® soit l’ajout dans votre base de données d’une colonne de type UUID (ou GUID) qui sera utilisée pour les échanges REST.
• NB : Depuis la version 3 de LightREST, les méthodes CipherID et DecipherID sont disponibles pour chiffrer/déchiffrer simplement et rapidement les identifiants automatiques.
• Vérifier systématiquement que l’utilisateur courant a un droit d’accès à la donnée qu’il souhaite récupérer (il a pu usurper un ID de base de données sur la session d’un autre utilisateur, ou bien son droits d’accès à la donnée à été révoqué entre temps).
• Vérifier également que l’utilisateur a un droit de modification en cas de requête en modification (ce n’est pas parce-qu’on peut lire une donnée qu’on a le droit de l’écrire ou de la supprimer).
• En règle générale, considérer tout accès et toute donnée extérieurs comme suspects. La paranoïa dans ce domaine est généralement une bonne compagne de la sécurité.