{"id":182,"date":"2023-08-23T18:39:40","date_gmt":"2023-08-23T16:39:40","guid":{"rendered":"http:\/\/127.0.0.1\/wordpress\/?page_id=182"},"modified":"2026-03-16T19:19:43","modified_gmt":"2026-03-16T17:19:43","slug":"lightrest-composant-rest-windev","status":"publish","type":"page","link":"https:\/\/lightrest.codeline.fr\/","title":{"rendered":"LightREST : Composant serveur API REST Open source pour WinDev\u00ae"},"content":{"rendered":"\n
\n

LightREST<\/mark><\/strong><\/mark><\/mark> est un composant gratuit et open source est destin\u00e9 aux d\u00e9veloppeurs WinDev<\/a>\u00ae<\/sup> souhaitant cr\u00e9er un Web Service<\/a> REST <\/a>(RE<\/strong>presentational S<\/strong>tate T<\/strong>ransfer).<\/p>\n\n\n\n

Contrairement au syst\u00e8me propos\u00e9 nativement par WinDev<\/a>\u00ae<\/sup>, LightREST<\/mark><\/strong><\/mark><\/mark> <\/mark><\/mark> ne n\u00e9cessite ni l\u2019installation d\u2019un serveur Web<\/strong> (IIS<\/a>, Apache<\/a>, \u2026) ni l’acquisition et les mises \u00e0 jour d’un serveur WebDev<\/a>\u00ae<\/sup><\/strong>. Les requ\u00eates API REST sont ex\u00e9cut\u00e9es directement par votre application WinDev<\/a>\u00ae<\/sup> sans subir un traitement chronophage par le serveur Web puis le serveur WebDev<\/a>\u00ae<\/sup>. Un serveur LightREST<\/mark><\/mark> <\/strong>\u00e9coute lui-m\u00eame l’interface r\u00e9seau et r\u00e9pond directement aux requ\u00eates REST<\/a>, sans aucun interm\u00e9diaire.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Disponible sous la forme d\u2019un composant Windows <\/a>32 et 64 bits et Linux<\/a> 64 bits, compatible avec toutes les versions WinDev<\/a>\u00ae<\/sup> \u00e0 partir de la V25, LightREST<\/mark><\/strong><\/mark><\/mark> a \u00e9t\u00e9 d\u00e9velopp\u00e9 et utilis\u00e9 depuis plusieurs ann\u00e9es par la soci\u00e9t\u00e9 CODE LINE<\/a>,<\/mark> qui se fait un plaisir de le mettre \u00e0 la disposition de la communaut\u00e9 des d\u00e9veloppeurs. La version 3 maintenant disponible apporte une performance accrue \u00e0 l’ex\u00e9cution et un confort d’utilisation am\u00e9lior\u00e9 pour le d\u00e9veloppeur WinDev\/WebDev.<\/p>\n\n\n\n

Le code de LightREST<\/mark><\/strong><\/mark><\/mark> est diffus\u00e9 sous licence MIT<\/u><\/strong><\/a>, ce qui laisse une enti\u00e8re libert\u00e9 pour le modifier et l’adapter aux besoins particulier, sans aucune obligation de partage (m\u00eame si les contributions au projet seront appr\u00e9ci\u00e9es).<\/p>\n\n\n\n

Avez-vous investi dans le d\u00e9veloppement d’une application lourde ou Web avec les outils PC SOFT<\/a>, dans laquelle vous avez impl\u00e9ment\u00e9 des fonctions m\u00e9tiers qui seraient fastidieuses \u00e0 porter vers d’autres technologies ? Comme les d\u00e9veloppeurs CODE LINE<\/a><\/mark>, vous pouvez utiliser LightREST<\/mark><\/strong><\/mark><\/mark> pour exploiter votre code w-langage\u00ae<\/sup> existant, transformer les fonctions m\u00e9tier en API REST. Et ensuite impl\u00e9menter un frontal Web (React<\/a>, VueJS<\/a>, Angular<\/a>, …), ou Mobile (WinDev Mobile<\/a>, Flutter<\/a>, Kotlin<\/a>, .NET<\/a>…) pour proposer des interfaces utilisateur modernes sans avoir \u00e0 migrer l’int\u00e9gralit\u00e9 du code vers une technologie alternative. CODE LINE<\/a><\/mark> est \u00e0 votre disposition pour vous accompagner dans cette d\u00e9marche voire pour r\u00e9aliser l’\u00e9volution de votre projet vers LightREST<\/mark><\/strong><\/mark><\/mark>.<\/p>\n\n\n\n

LightREST<\/mark><\/strong><\/mark><\/mark> fonctionne en mode HTTP <\/a>et HTTPS<\/a>, et int\u00e8gre un g\u00e9n\u00e9rateur automatique de certificat <\/strong>SSL 2048 bits<\/strong><\/a> ce qui permet de b\u00e9n\u00e9ficier du chiffrage HTTPS <\/a>sans acqu\u00e9rir un certificat. Evidemment, il reste possible d’utiliser un certificat SSL existant, sign\u00e9 par une autorit\u00e9 reconnue. Depuis la version 2.7 LightREST<\/mark><\/strong><\/mark><\/mark> peut \u00e9galement g\u00e9n\u00e9rer vos certificats Let’s Encrypt<\/a><\/strong>, et les renouveler automatiquement !<\/p>\n\n\n\n

Il peut fonctionner soit sous la forme d’un ex\u00e9cutable \u00ab\u00a0standard\u00a0\u00bb (fen\u00eatr\u00e9 ou pas), ou en tant que service, que ce soit sous Windows 32\/64 <\/em>ou sous Linux<\/em>. <\/p>\n<\/div>\n\n\n\n

LightREST<\/mark><\/strong><\/mark><\/mark> est utilis\u00e9 depuis plusieurs ann\u00e9es en production, et sa r\u00e9cente version 3 apporte des am\u00e9liorations notables en terme de performance, de stabilit\u00e9 mais aussi de confort et d’efficacit\u00e9 pour le d\u00e9veloppeur (comme le m\u00e9canisme de HOOKs qui permet de centraliser des traitements transverses). La liste des nouveaut\u00e9s V3 ICI.<\/p>\n\n\n\n

\n

LightREST<\/mark><\/strong><\/mark><\/mark> permet de d\u00e9ployer un serveur API REST en quelques lignes de code w-langage<\/a>\u00ae<\/sup> \u00e0 la port\u00e9e de tout d\u00e9veloppeur, sans param\u00e9trage fastidieux (voir ICI<\/strong><\/u><\/a> et ICI<\/u><\/strong><\/a> le m\u00e9canisme natif de WinDev<\/a>\u00ae<\/sup>) :<\/p>\n\n\n\n

\n
\n

D\u00e9marrage d’un serveur LightREST<\/mark><\/strong><\/mark><\/mark> et cr\u00e9ation d’une route :<\/p>\n\n\n\n

oServer\test objet lrServer\noRoute  est objet lrRoute\nbOK\test bool\u00e9en\ncErr\test cha\u00eene\n\n\/\/Cr\u00e9ation de la route \/getdata qui appelera la proc\u00e9dure interne piTestGET\noRoute:Route   = \"\/getdata\/{nb}\"\noRoute.Method  = lrRoute::MethodGET\noRoute.Handler = piTestGET\noServer:AddRoute(oRoute)\n\n\/\/On va \u00e9couter le port 9000\noServer:IPAndPort = \"0.0.0.0:9000\"\n\n\/\/C'est parti mon Kiki\n(bOK, cErr) = oServer:Start()\nSI pas bOK ALORS\n    Info(\"Erreur lors du d\u00e9marrage du serveur REST\", cErr)\n    RETOUR\nFIN\n\nInfo(\"Click to close LightREST server\")\n\noServer:Terminate()\n\n\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\n\nPROC\u00c9DURE interne piTestGET(poReq objet lrRequest) : lrResponse\n    oResponse est objet lrResponse\n    eNb       est entier\n\n    oResponse:Body = \"Pong \"+HeureSys()\n\n    \/\/On r\u00e9cup\u00e8re la variable nb dans la Route REST\n    eNb = Val(poReq:GetRouteValue(\"nb\"))\n\n    SI eNb>100 ALORS\n        oResponse:Status = lrResponse::StatusBadRequest\n        oResponse:Body   = \"Maxi = 100\"\n    SINON\n        InitHasard()\n        POUR i=1 _\u00c0_ eNb\n            oResponse:Body += [CRLF] + Hasard(1, 1000)\n        FIN\n        oResponse:Status      = lrResponse::StatusOK\n    FIN\n\n    oResponse:ContentType = lrResponse::ContentTXT\n    RENVOYER oResponse\nFIN<\/code><\/pre>\n\n\n\n
Voil\u00e0, nous avons un serveur API REST qui \u00e9coute sur le port 9000 (tel que param\u00e9tr\u00e9 avec l’objet oServer<\/strong><\/a><\/em>) et pr\u00eat \u00e0 ex\u00e9cuter du code lorsque la route \/getdata est appel\u00e9e.

La proc\u00e9dure interne qui impl\u00e9mente le handler piTestGET est d\u00e9finie comme ci-dessous. Elle utilise les objets poReq <\/em><\/strong>de type lrRequest <\/a>(qui contient la requ\u00eate API REST re\u00e7ue) et oResponse<\/strong><\/a><\/em> de type lrResponse <\/a>(qui sera utilis\u00e9 pour renvoyer le r\u00e9sultat de la requ\u00eate). Elle va renvoyer \u201cPong<\/em>\u201c+l\u2019heure syst\u00e8me, et une liste de nb<\/em> entiers au hasard (nb \u00e9tant le param\u00e8tre pass\u00e9 dans la route).

G\u00e9n\u00e9ralement on utilise un format structur\u00e9 comme JSON pour \u00e9changer des donn\u00e9es avec une API REST. Dans cet exemple on renvoie une simple cha\u00eene de caract\u00e8re.<\/em><\/p>\n<\/div>\n\n\n\n
<\/p>\n<\/div>\n\n\n\n
\n\n\n\n
\n
Ensuite pour tester, dans un simple appel dans un navigateur Web :<\/p>\n\n\n\n
http://127.0.0.1:9000\/getdata\/10<\/code><\/pre>\n\n\n\n
va renvoyer le r\u00e9sultat suivant :<\/p>\n\n\n\n
Pong 03304860\n817\n805\n719\n569\n75\n404\n324\n1000\n701\n793<\/code><\/pre>\n<\/div>\n\n\n\n
\n
Encore mieux, en utilisant un vrai client REST comme POSTMAN<\/strong><\/u><\/a>, on peut constater que le statut 400 (bad request) est bien retourn\u00e9 si le param\u00e8tre re\u00e7u est sup\u00e9rieur \u00e0 100 :<\/p>\n\n\n\n
\"\"<\/figure>\n<\/div>\n\n\n\n
Envie d\u2019en savoir plus sur LightREST<\/strong><\/mark> ? Consultez le Guide de d\u00e9marrage<\/u><\/a> et la Documentation<\/u><\/a>.
<\/p>\n\n\n\n
\n\n\n\n
L’AGL WinDev est reconnu pour sa puissance et sa polyvalence dans le d\u00e9veloppement logiciel. En combinant les capacit\u00e9s de WinDev avec l’utilisation de Web Services REST, les d\u00e9veloppeurs b\u00e9n\u00e9ficient d’une synergie exceptionnelle.<\/p>\n\n\n\n
Tout d’abord, WinDev offre un environnement de d\u00e9veloppement int\u00e9gr\u00e9 (EDI) complet, permettant une conception rapide et efficace d’applications. Sa simplicit\u00e9 d’utilisation et sa richesse fonctionnelle en font un outil de choix pour les d\u00e9veloppeurs, offrant des fonctionnalit\u00e9s \u00e9tendues pour la cr\u00e9ation d’applications professionnelles, desktop ou web.<\/p>\n\n\n\n
L’int\u00e9gration des Web Services REST dans WinDev offre des avantages consid\u00e9rables. Les Web Services REST permettent une communication simple et efficace entre diff\u00e9rentes plateformes et applications, favorisant ainsi l’interop\u00e9rabilit\u00e9. Cette approche bas\u00e9e sur les standards du web offre une flexibilit\u00e9 in\u00e9gal\u00e9e, permettant l’\u00e9change de donn\u00e9es entre des syst\u00e8mes h\u00e9t\u00e9rog\u00e8nes de mani\u00e8re s\u00e9curis\u00e9e et scalable.<\/p>\n\n\n\n
En utilisant les Web Services REST avec WinDev, les d\u00e9veloppeurs peuvent tirer parti des fonctionnalit\u00e9s distribu\u00e9es, am\u00e9liorant la modularit\u00e9 et la flexibilit\u00e9 des applications. Cette approche favorise \u00e9galement la r\u00e9utilisabilit\u00e9 du code et la maintenance simplifi\u00e9e des syst\u00e8mes, r\u00e9duisant ainsi les co\u00fbts de d\u00e9veloppement \u00e0 long terme.<\/p>\n\n\n\n
De plus, l’utilisation des API REST facilite l’int\u00e9gration des applications avec des services tiers, tels que des services cloud, des API externes ou des plateformes de donn\u00e9es, ouvrant ainsi de vastes possibilit\u00e9s pour l’expansion et l’enrichissement des fonctionnalit\u00e9s des applications d\u00e9velopp\u00e9es avec WinDev.<\/p>\n\n\n\n
En r\u00e9sum\u00e9, l’association de l’AGL WinDev avec l’utilisation des Web Services REST offre une combinaison puissante pour le d\u00e9veloppement logiciel, permettant une conception rapide, une interop\u00e9rabilit\u00e9 \u00e9tendue, une flexibilit\u00e9 accrue et une int\u00e9gration transparente avec des services externes, offrant ainsi des solutions logicielles robustes et \u00e9volutives pour r\u00e9pondre aux besoins actuels et futurs.\u00a0\u00bb<\/p>\n\n\n\n
Cette combinaison peut vraiment \u00eatre b\u00e9n\u00e9fique dans de nombreux contextes de d\u00e9veloppement logiciel !<\/p>\n\n\n\n
\n\n\n\n
Le composant LightREST<\/mark><\/strong><\/mark><\/mark> est souvent appr\u00e9ci\u00e9 pour plusieurs raisons. Voici quelques-uns de ses avantages cl\u00e9s :<\/p>\n\n\n\n
    \n
  1. Facilit\u00e9 d’utilisation :<\/strong> LightREST<\/mark><\/strong><\/mark><\/mark> simplifie la cr\u00e9ation et la gestion des API REST dans les applications. Ses classes faciles d’usage permettent aux d\u00e9veloppeurs de mettre en place rapidement des points de terminaison REST sans une courbe d’apprentissage complexe.<\/li>\n\n\n\n
  2. L\u00e9g\u00e8ret\u00e9 :<\/strong> Comme son nom l’indique, LightREST<\/mark><\/strong><\/mark><\/mark> est con\u00e7u pour \u00eatre l\u00e9ger. Il offre une solution simplifi\u00e9e pour la cr\u00e9ation de Web Services REST sans ajouter de complexit\u00e9 inutile \u00e0 l’application. Cela peut contribuer \u00e0 des performances am\u00e9lior\u00e9es et \u00e0 une consommation minimale de ressources.<\/li>\n\n\n\n
  3. Rapidit\u00e9 de d\u00e9ploiement :<\/strong> En raison de sa simplicit\u00e9 et de sa l\u00e9g\u00e8ret\u00e9, LightREST<\/mark><\/strong><\/mark><\/mark> permet un d\u00e9ploiement rapide des services. Les d\u00e9veloppeurs peuvent cr\u00e9er et impl\u00e9menter des services REST de mani\u00e8re efficace, acc\u00e9l\u00e9rant ainsi le cycle de d\u00e9veloppement.<\/li>\n\n\n\n
  4. Int\u00e9gration ais\u00e9e :<\/strong> LightREST<\/mark><\/strong><\/mark><\/mark> s’int\u00e8gre g\u00e9n\u00e9ralement bien avec d’autres composants et solutions logicielles, offrant une compatibilit\u00e9 et une interop\u00e9rabilit\u00e9 \u00e9lev\u00e9es avec diff\u00e9rentes plates-formes et technologies.<\/li>\n\n\n\n
  5. Maintenance simplifi\u00e9e :<\/strong> Gr\u00e2ce \u00e0 son approche simplifi\u00e9e, la maintenance des services cr\u00e9\u00e9s avec LightREST<\/mark><\/strong><\/mark><\/mark> peut \u00eatre moins complexe. Les d\u00e9veloppeurs peuvent facilement comprendre et mettre \u00e0 jour les points de terminaison REST, facilitant ainsi la gestion \u00e0 long terme des services.<\/li>\n<\/ol>\n\n\n\n
    En somme, le composant LightREST<\/mark><\/strong><\/mark><\/mark> offre une approche l\u00e9g\u00e8re, simple et conviviale pour la cr\u00e9ation de Web Services REST, ce qui en fait un choix attrayant pour les d\u00e9veloppeurs cherchant \u00e0 impl\u00e9menter rapidement des fonctionnalit\u00e9s de communication et d’int\u00e9gration dans leurs applications.<\/p>\n<\/div>\n\n\n\n
    \n\n\n\n
    Comment le moteur d’IA ChatGPT <\/a>explique-t-il les meilleurs performances de WinDev<\/a>+LightREST<\/mark><\/strong><\/mark><\/mark><\/u> par rapport \u00e0 WinDev<\/a>+serveur <\/u>WebDev<\/u> <\/a>?
    Voici sa r\u00e9ponse in extenso<\/em> du 28\/03\/2025 :<\/p>\n\n\n\n
    Le composant LightREST pour WinDev, d\u00e9velopp\u00e9 par CODE LINE, permet de cr\u00e9er des serveurs API REST. Il existe \u00e9galement une fonctionnalit\u00e9 native dans WinDev pour la cr\u00e9ation de serveurs API REST, mais LightREST peut offrir des avantages en termes de performance. Voici quelques \u00e9l\u00e9ments qui peuvent expliquer pourquoi LightREST peut \u00eatre plus performant que la solution native de WinDev.\n\n1. Optimisation des performances r\u00e9seau\n   - LightREST est sp\u00e9cialement con\u00e7u pour g\u00e9rer des APIs REST de mani\u00e8re l\u00e9g\u00e8re et optimis\u00e9e. Cela signifie qu'il est probablement con\u00e7u pour minimiser les latences et optimiser la gestion des requ\u00eates HTTP. Cela peut \u00eatre particuli\u00e8rement important lorsqu'il y a un grand nombre de requ\u00eates simultan\u00e9es ou lorsqu'une r\u00e9ponse rapide est requise.\n   - Le composant est optimis\u00e9 pour traiter les requ\u00eates en utilisant un minimum de ressources syst\u00e8me (par exemple, m\u00e9moire et CPU), ce qui peut am\u00e9liorer le temps de r\u00e9ponse des API.\n\n2. Simplicit\u00e9 et l\u00e9g\u00e8ret\u00e9\n- LightREST met l'accent sur la l\u00e9g\u00e8ret\u00e9 et la simplicit\u00e9 de l'impl\u00e9mentation. Il peut ne pas comporter de fonctionnalit\u00e9s complexes ou de couches suppl\u00e9mentaires qui sont souvent pr\u00e9sentes dans les solutions natives. Cela peut r\u00e9duire les overheads (charges suppl\u00e9mentaires) et donc am\u00e9liorer les performances de traitement.\n   - En comparaison, la solution native de WinDev, bien qu'efficace, peut \u00eatre plus riche en fonctionnalit\u00e9s par d\u00e9faut, ce qui peut parfois augmenter la consommation de ressources et le temps de traitement.\n\n3. Personnalisation et ajustement fin\n   - LightREST permet souvent plus de contr\u00f4le sur les param\u00e8tres de gestion des requ\u00eates et des r\u00e9ponses. Cela permet aux d\u00e9veloppeurs de configurer les comportements de mise en cache, de compression ou de gestion des erreurs pour maximiser les performances. Ces param\u00e8tres peuvent avoir un impact significatif sur la rapidit\u00e9 des \u00e9changes et sur la gestion des charges importantes.\n   - La solution native de WinDev, quant \u00e0 elle, est plus g\u00e9n\u00e9rique et moins flexible, offrant moins de possibilit\u00e9s pour ajuster finement la gestion des ressources et des requ\u00eates.\n\n4. Ciblage sp\u00e9cifique de l'API REST\n- LightREST est d\u00e9di\u00e9 exclusivement \u00e0 la cr\u00e9ation d'APIs REST, ce qui signifie qu'il peut \u00eatre optimis\u00e9 pour ce cas d'usage sp\u00e9cifique. Il peut int\u00e9grer des pratiques de d\u00e9veloppement plus efficaces et des optimisations adapt\u00e9es pour le protocole HTTP et les donn\u00e9es JSON, qui sont couramment utilis\u00e9s dans les APIs REST.\n   - WinDev, avec sa solution native, est un environnement de d\u00e9veloppement plus large et offre une multitude de fonctionnalit\u00e9s, mais cela peut parfois rendre le traitement d'APIs REST moins sp\u00e9cialis\u00e9 et donc un peu moins performant pour des applications \u00e0 grande \u00e9chelle.\n\n5. Gestion des ressources (m\u00e9moire, threads)\n   - LightREST est con\u00e7u pour \u00eatre particuli\u00e8rement l\u00e9ger en termes de gestion de m\u00e9moire et de threads, ce qui peut aider \u00e0 g\u00e9rer un grand nombre de requ\u00eates simultan\u00e9es tout en optimisant la consommation des ressources.\n   - Dans WinDev, bien que performant, le serveur REST natif peut parfois \u00eatre plus gourmand en ressources ou plus complexe dans la gestion des connexions simultan\u00e9es, notamment s'il faut g\u00e9rer un grand nombre de clients ou des requ\u00eates complexes.\n\n6. Mise en cache et compression\n- LightREST peut inclure des fonctionnalit\u00e9s avanc\u00e9es pour la mise en cache des r\u00e9ponses API et la compression des donn\u00e9es \u00e9chang\u00e9es. Ces techniques permettent de r\u00e9duire la charge sur le serveur et d'am\u00e9liorer la rapidit\u00e9 des r\u00e9ponses, en particulier pour des donn\u00e9es fr\u00e9quemment demand\u00e9es.\n   - Bien que WinDev offre des m\u00e9canismes de cache, la mise en \u0153uvre peut ne pas \u00eatre aussi pouss\u00e9e ou optimis\u00e9e de mani\u00e8re aussi sp\u00e9cifique qu'avec un composant comme LightREST.\n\n7. Utilisation de protocoles l\u00e9gers\n   - LightREST peut aussi tirer parti de protocoles l\u00e9gers et d'une architecture minimaliste qui permettent de r\u00e9pondre plus rapidement et de mani\u00e8re plus efficace, en se concentrant uniquement sur les fonctionnalit\u00e9s n\u00e9cessaires \u00e0 la gestion des APIs REST, sans int\u00e9grer de fonctionnalit\u00e9s suppl\u00e9mentaires qui pourraient nuire aux performances.\n\nEn r\u00e9sum\u00e9 :\nLightREST peut offrir une meilleure performance que la solution native de WinDev pour plusieurs raisons, notamment son optimisation pour les API REST, son l\u00e9g\u00e8ret\u00e9, son contr\u00f4le plus pr\u00e9cis des ressources et des performances, ainsi que des fonctionnalit\u00e9s comme la mise en cache et la compression des r\u00e9ponses. Tandis que la solution native de WinDev est plus g\u00e9n\u00e9rique et int\u00e9gr\u00e9e dans un environnement plus large, LightREST est sp\u00e9cifiquement con\u00e7u pour \u00eatre rapide, l\u00e9ger et performant dans la gestion des API REST.\n\nSi la performance est un crit\u00e8re essentiel dans ton projet, notamment pour des applications \u00e0 forte charge, LightREST pourrait donc \u00eatre une solution plus adapt\u00e9e que l'option native de WinDev.<\/code><\/pre>\n\n\n\n
    <\/p>\n\n\n\n

    ChatGPT <\/a>ayant particip\u00e9 \u00e0 la r\u00e9daction de la documentation de LightREST V3, il a pu am\u00e9liorer son analyse.
    Voici son avis in extenso<\/em> le 07\/02\/2026 :<\/p>\n\n\n\n
    Quand on constate, chiffres \u00e0 l\u2019appui, qu\u2019une API WinDev + LightREST r\u00e9pond plus vite (et tient mieux la charge) qu\u2019une API WinDev + serveur WebDev, la tentation est de conclure : *\u201cLightREST est plus rapide.\u201d*\nEn r\u00e9alit\u00e9, la diff\u00e9rence ne vient pas d\u2019un \u201cmiracle\u201d, mais d\u2019une s\u00e9rie de choix d\u2019architecture tr\u00e8s concrets : r\u00e9duire le chemin critique d\u2019une requ\u00eate, limiter les surcouches inutiles pour du REST, et mieux contr\u00f4ler ce qui se passe sous forte charge.\n\nCet article explique *pourquoi* \u2014 avec des \u00e9l\u00e9ments plus pr\u00e9cis que les arguments g\u00e9n\u00e9riques du type \u201cc\u2019est plus l\u00e9ger\u201d.\n\n---\n\n1) La performance d\u2019une API, ce n\u2019est pas seulement le code m\u00e9tier\n\nDans les deux solutions, ton code m\u00e9tier est en WLangage. Donc l\u2019\u00e9cart de performance vient surtout de tout ce qui entoure ce code :\n\n* parsing HTTP (headers, querystring, body, multipart\u2026)\n* routage vers la bonne m\u00e9thode\n* gestion de la concurrence (requ\u00eates simultan\u00e9es)\n* conversions (strings\/buffer\/binaire\/JSON)\n* politique de timeouts, annulation, nettoyage des clients inactifs\n* construction de la r\u00e9ponse (status, headers, body)\n\nUne API rapide, c\u2019est avant tout une API dont le \u201cplancher\u201d de co\u00fbt par requ\u00eate est bas, stable, et ma\u00eetris\u00e9.\n\n---\n\n2) Serveur WebDev : excellent\u2026 mais g\u00e9n\u00e9raliste\n\nLe serveur WebDev est un serveur d\u2019application : il sait faire beaucoup de choses (h\u00e9bergement, logique web, int\u00e9gration \u00e0 l\u2019\u00e9cosyst\u00e8me WebDev, comportements \u201cpr\u00eats \u00e0 l\u2019emploi\u201d). Cette g\u00e9n\u00e9ralit\u00e9 est un avantage\u2026 *mais elle a un co\u00fbt*.\n\nQuand ton objectif est une API REST \u201cpure\u201d :\n\n* tu n\u2019as pas besoin d\u2019une partie des m\u00e9caniques d\u2019un serveur d\u2019application,\n* mais tu payes quand m\u00eame une partie de ces couches,\n* et surtout tu as moins de leviers pour \u201ctailler\u201d finement le runtime autour de tes routes API.\n\n---\n\n3) LightREST : r\u00e9duire le chemin critique (le \u201cchemin court\u201d)\n\nLightREST est pens\u00e9 \u201cAPI-first\u201d, avec une philosophie code-first : on d\u00e9crit les routes et comportements en code, on \u00e9vite l\u2019empilement de configuration et d\u2019artefacts, et on vise un traitement direct.\n\n#Routage plus direct et plus structur\u00e9\n\nSur LightREST V3, la logique de route est plus structur\u00e9e (objet lrRoute), et l\u2019objectif est clair : *aller vite de \u201cHTTP\u201d \u00e0 \u201cproc\u00e9dure WLangage\u201d*.\n\nExemple (pseudo-code) :\n\ntext\n\/\/ D\u00e9claration code-first : m\u00e9thode + pattern + proc\u00e9dure\nAddRoute(\"GET\",  \"\/clients\/{id}\",  Proc_GetClient)\nAddRoute(\"POST\", \"\/clients\",       Proc_CreateClient)\n\n\nCe style \u201ccode-first\u201d n\u2019am\u00e9liore pas que l\u2019ergonomie : il r\u00e9duit souvent l\u2019overhead li\u00e9 \u00e0 des m\u00e9canismes plus g\u00e9n\u00e9riques et te donne un contr\u00f4le plus fin sur ce que fait r\u00e9ellement le serveur.\n\n---\n\n4) lrRequest et lrResponse : moins de glue, moins de copies, moins d\u2019implicite\n\nUne partie non n\u00e9gligeable du temps \u201cperdu\u201d sur une API vient du glue code : r\u00e9cup\u00e9rer les headers, parser l\u2019URL, extraire des variables de route, g\u00e9rer les fichiers, convertir des formats, etc.\n\nLightREST fournit des objets d\u00e9di\u00e9s, typ\u00e9s \u201cusage API\u201d :\n\n* lrRequest : headers, variables de route, querystring, body, fichiers, donn\u00e9es custom, auth\u2026\n* lrResponse : status, headers, content-type, body, binaire\u2026\n\nPlus tu r\u00e9duis les op\u00e9rations \u201cautour\u201d, plus tu rapproches la perf r\u00e9elle de ton code m\u00e9tier.\n\n#Point tr\u00e8s parlant : les uploads\n\nSur beaucoup d\u2019APIs, les fichiers (multipart\/form-data) font exploser le co\u00fbt par requ\u00eate : I\/O disque, fichiers temporaires, copies, conversions.\n\nLightREST expose les fichiers dans la requ\u00eate avec une approche \u201cpr\u00eate \u00e0 traiter\u201d (contenu accessible directement). Selon tes cas d\u2019usage, \u00e7a peut \u00e9viter une partie des m\u00e9caniques indirectes (temp file + relecture), et \u00e7a se traduit tr\u00e8s vite en :\n\n* moins de latence,\n* moins d\u2019I\/O,\n* moins de contention.\n\n(\u00c9videmment : pour de tr\u00e8s gros fichiers, il faut une strat\u00e9gie m\u00e9moire coh\u00e9rente. Mais l\u2019important ici, c\u2019est que LightREST rend ce point ma\u00eetrisable et explicite.)\n\n---\n\n5) La perf \u201cqui compte\u201d : celle sous charge (p95\/p99), pas juste le temps moyen\n\nUne API peut afficher 10 ms en moyenne\u2026 et devenir catastrophique sous charge si elle ne g\u00e8re pas bien :\n\n* le nombre de requ\u00eates simultan\u00e9es\n* les clients inactifs\n* les requ\u00eates \u201cmortes\u201d (client parti, socket coup\u00e9)\n* les timeouts\n* les acc\u00e8s concurrents aux donn\u00e9es partag\u00e9es\n\nSur LightREST V3, il y a justement des choix qui jouent \u00e9norm\u00e9ment sur la stabilit\u00e9 des temps de r\u00e9ponse :\n\n#Limitation des requ\u00eates simultan\u00e9es (back-pressure)\n\nPouvoir limiter le nombre de requ\u00eates en parall\u00e8le est un levier majeur.\nPlut\u00f4t que de laisser le serveur partir en \u201cthrash\u201d (CPU \u00e0 100%, RAM qui grimpe, temps de r\u00e9ponse qui explose), tu imposes une pression contr\u00f4l\u00e9e.\n\nR\u00e9sultat typique :\n\n* un d\u00e9bit l\u00e9g\u00e8rement plafonn\u00e9,\n* mais des latences beaucoup plus stables (notamment p95\/p99).\n\n#Timeouts globaux et par route\n\nUne route \u201clente\u201d (ou un appel externe qui bloque) peut contaminer tout le serveur si elle monopolise des ressources trop longtemps.\n\nLe fait d\u2019avoir des timeouts configurables globalement et par route permet de garder une API \u201cvivante\u201d, m\u00eame quand une d\u00e9pendance externe se d\u00e9grade.\n\n#Annulation automatique des requ\u00eates mortes + gestion des clients inactifs\n\nNettoyer automatiquement les connexions \/ clients inactifs et annuler les requ\u00eates devenues inutiles, ce n\u2019est pas juste \u201cpropre\u201d : c\u2019est de la performance.\nTu lib\u00e8res des ressources et tu \u00e9vites les accumulations invisibles qui finissent en d\u00e9gradation progressive.\n\n#Compartimentation \/ s\u00e9curisation des threads\n\nQuand une API commence \u00e0 bien charger, les bugs de concurrence (donn\u00e9es partag\u00e9es mal prot\u00e9g\u00e9es, \u00e9tats globaux, caches mal g\u00e9r\u00e9s) cr\u00e9ent des comportements erratiques : ralentissements, blocages, latences al\u00e9atoires.\n\nLe fait que LightREST V3 mette l\u2019accent sur la s\u00e9curisation des threads et une meilleure isolation des contextes contribue directement \u00e0 la constance des performances.\n\n---\n\n6) Moteur optimis\u00e9 et composant all\u00e9g\u00e9 : CPU et m\u00e9moire plus \u201cpropres\u201d\n\nDeux points tr\u00e8s concrets de LightREST V3, qui comptent dans la vraie vie :\n\n* optimisations moteur (jusqu\u2019\u00e0 +50% selon sc\u00e9narios)\n* r\u00e9duction de la taille du composant (environ -40%)\n\nPourquoi \u00e7a joue ?\n\n* moins de code \/ moins de couches = moins d\u2019initialisation, moins de m\u00e9moire, moins d\u2019effets de bord\n* une empreinte plus faible aide la stabilit\u00e9 (cache CPU, GC, fragmentation m\u00e9moire, etc.)\n* sous charge, le \u201cbruit\u201d diminue : la machine d\u00e9pense plus d\u2019\u00e9nergie sur le m\u00e9tier, moins sur le runtime\n\n---\n\n7) Hooks before\/after : performance + observabilit\u00e9\n\nLes hooks globaux (*before \/ after*) sont un outil tr\u00e8s puissant :\n\n* instrumentation (mesures de temps par route)\n* enrichissement \/ normalisation des r\u00e9ponses\n* contr\u00f4le centralis\u00e9 des erreurs\n* politique de s\u00e9curit\u00e9 uniforme\n* journalisation coh\u00e9rente\n\nEt surtout : \u00e7a permet d\u2019\u00e9viter de r\u00e9p\u00e9ter du code \u201cp\u00e9riph\u00e9rique\u201d dans chaque m\u00e9thode, ce qui, encore une fois, r\u00e9duit les co\u00fbts cach\u00e9s et les incoh\u00e9rences (qui finissent toujours par co\u00fbter en perf).\n\n---\n\n8) Quand l\u2019\u00e9cart se voit le plus (et quand il se voit moins)\n\nL\u2019\u00e9cart en faveur de LightREST est g\u00e9n\u00e9ralement maximal quand :\n\n* tu as beaucoup de routes simples (APIs CRUD, microservices)\n* tu as beaucoup de requ\u00eates simultan\u00e9es\n* tu fais des payloads JSON petits \u00e0 moyens\n* tu veux des p95\/p99 stables (et pas seulement \u201crapide en moyenne\u201d)\n* tu veux contr\u00f4ler finement : timeouts, limite concurrency, annulation, monitoring\n\nL\u2019\u00e9cart se r\u00e9duit quand :\n\n* le goulot est ailleurs (HFSQL mal index\u00e9, requ\u00eates lentes, traitements lourds)\n* ta route fait 500 ms de m\u00e9tier : gagner 3 ms d\u2019overhead n\u2019est pas visible\n* ton architecture r\u00e9seau \/ d\u00e9pendances externes dominent la latence\n\n---\n\n9) Comment le prouver proprement (et produire un comparatif cr\u00e9dible)\n\nSi tu veux un comparatif publiable, fais simple :\n\n1. M\u00eame machine \/ m\u00eames donn\u00e9es \/ m\u00eame code m\u00e9tier WLangage\n2. Sc\u00e9nario de charge r\u00e9aliste (k6, wrk, JMeter\u2026) :\n\n   * ramp-up\n   * plateau (ex : 100, 300, 500 VU)\n3. Mesures :\n\n   * p50 \/ p95 \/ p99\n   * CPU \/ RAM\n   * erreurs \/ timeouts\n4. Cas \u201cdifficile\u201d :\n\n   * route lente simul\u00e9e\n   * d\u00e9pendance externe qui r\u00e9pond mal\n   * upload fichier\n\nC\u2019est souvent l\u00e0 que LightREST fait la diff\u00e9rence : il ne s\u2019\u00e9croule pas, ou beaucoup moins vite.\n\n---\n\nConclusion\n\nLe gain de performance de WinDev + LightREST face \u00e0 WinDev + serveur WebDev ne vient pas d\u2019une magie obscure : il vient d\u2019un ensemble coh\u00e9rent de choix \u201cAPI-first\u201d :\n\n* chemin critique plus court\n* objets requ\u00eate\/r\u00e9ponse pens\u00e9s pour le REST\n* contr\u00f4le de la concurrence (limite simultan\u00e9e)\n* timeouts globaux et par route\n* annulation et nettoyage automatique (clients inactifs \/ requ\u00eates mortes)\n* meilleure s\u00e9curit\u00e9 de threading\n* moteur optimis\u00e9 et composant all\u00e9g\u00e9\n* hooks before\/after pour industrialiser sans r\u00e9p\u00e9ter\n\nEn bref : WebDev est un couteau suisse, LightREST est un scalpel.\nPour une API REST qui doit \u00eatre rapide, stable et ma\u00eetrisable sous charge, le scalpel gagne tr\u00e8s souvent.\n\n---\n<\/code><\/pre>\n\n\n\n

    En compl\u00e9ment, voici l’analyse de ChatGPT sur la principale nouveaut\u00e9 de LightREST V3, les Hooks :
    <\/p>\n\n\n\n
    Lorsqu\u2019un serveur REST commence \u00e0 \u00eatre utilis\u00e9 dans des contextes professionnels ou industriels, les besoins d\u00e9passent rapidement la simple ex\u00e9cution de routes HTTP. Les d\u00e9veloppeurs doivent g\u00e9rer des pr\u00e9occupations transverses telles que l\u2019authentification, la journalisation, la supervision, la s\u00e9curit\u00e9 ou encore la gouvernance des API.\n\nDans ce type d\u2019architecture, il devient essentiel de pouvoir intervenir \u00e0 diff\u00e9rents moments du cycle de traitement d\u2019une requ\u00eate, sans pour autant complexifier les proc\u00e9dures m\u00e9tier elles-m\u00eames.\n\nC\u2019est pr\u00e9cis\u00e9ment le r\u00f4le du m\u00e9canisme de hooks int\u00e9gr\u00e9 dans LightREST. Ce syst\u00e8me permet d\u2019ins\u00e9rer des points d\u2019extension contr\u00f4l\u00e9s dans le pipeline interne du serveur HTTP, afin d\u2019intercepter, d\u2019observer ou de modifier le traitement des requ\u00eates REST.\n\nDans une API REST classique, chaque route correspond \u00e0 une proc\u00e9dure m\u00e9tier. Cependant, certaines op\u00e9rations ne rel\u00e8vent pas directement de la logique m\u00e9tier :\n- journaliser les requ\u00eates entrantes\n- v\u00e9rifier une authentification\n- contr\u00f4ler les acc\u00e8s par adresse IP\n- mesurer les temps d\u2019ex\u00e9cution\n- enrichir les r\u00e9ponses avec des m\u00e9tadonn\u00e9es\n- normaliser les erreurs\n- tracer les appels pour un audit\n\nSans m\u00e9canisme d\u00e9di\u00e9, ces traitements doivent \u00eatre impl\u00e9ment\u00e9s directement dans chaque route. Cette approche pr\u00e9sente plusieurs inconv\u00e9nients :\n- duplication du code\n- risque d\u2019incoh\u00e9rences\n- complexit\u00e9 accrue des proc\u00e9dures\n- difficult\u00e9 de maintenance\n\nLes hooks permettent de r\u00e9soudre ce probl\u00e8me en introduisant une architecture \u00e9v\u00e9nementielle interne, dans laquelle certaines fonctions peuvent \u00eatre d\u00e9clench\u00e9es automatiquement \u00e0 des moments pr\u00e9cis du traitement d\u2019une requ\u00eate. Cette approche permet de centraliser les pr\u00e9occupations transverses tout en gardant les proc\u00e9dures REST simples et lisibles.\n\nLorsqu\u2019une requ\u00eate HTTP arrive sur un serveur LightREST, elle traverse plusieurs phases internes avant que la r\u00e9ponse ne soit envoy\u00e9e au client.\nLe m\u00e9canisme de hooks permet d\u2019intervenir \u00e0 diff\u00e9rents moments de ce pipeline.\n\nSch\u00e9matiquement, le traitement d\u2019une requ\u00eate suit les \u00e9tapes suivantes :\n- r\u00e9ception de la requ\u00eate HTTP\n- analyse de la requ\u00eate\n- recherche de la route correspondante\n- ex\u00e9cution de la proc\u00e9dure REST\n- construction de la r\u00e9ponse\n- envoi de la r\u00e9ponse au client\n\nLes hooks permettent d\u2019ins\u00e9rer des traitements personnalis\u00e9s autour de ces \u00e9tapes.\nPar exemple :\n- au moment de la r\u00e9ception d\u2019une requ\u00eate\n- juste avant l\u2019ex\u00e9cution d\u2019une m\u00e9thode REST\n- juste apr\u00e8s son ex\u00e9cution\n- avant l\u2019envoi de la r\u00e9ponse\n- lors de la survenue d\u2019une erreur\n\nCette architecture transforme le serveur REST en pipeline programmable, capable d\u2019int\u00e9grer facilement des traitements suppl\u00e9mentaires sans modifier les routes elles-m\u00eames.\n\nL\u2019un des principaux int\u00e9r\u00eats des hooks est de permettre la gestion centralis\u00e9e de ce que l\u2019on appelle les pr\u00e9occupations transverses (cross-cutting concerns).\nPar exemple, l\u2019authentification peut \u00eatre impl\u00e9ment\u00e9e dans un hook ex\u00e9cut\u00e9 avant chaque route, plut\u00f4t que dans chaque proc\u00e9dure REST.\nDe la m\u00eame mani\u00e8re, la journalisation peut \u00eatre r\u00e9alis\u00e9e dans un hook unique qui enregistre automatiquement toutes les requ\u00eates et leurs r\u00e9ponses.\nCette approche pr\u00e9sente plusieurs avantages :\n- simplification des proc\u00e9dures m\u00e9tier\n- meilleure coh\u00e9rence du syst\u00e8me\n- maintenance facilit\u00e9e\n- r\u00e9duction des duplications de code.\n\nDans une architecture d\u2019API moderne, ce type de m\u00e9canisme est essentiel pour construire des syst\u00e8mes robustes et \u00e9volutifs. Il ouvre la porte \u00e0 de nombreux sc\u00e9narios d\u2019industrialisation des API.\n\nPar exemple :\n- journalisation centralis\u00e9e\n- contr\u00f4le d\u2019acc\u00e8s\n- mesure des temps d\u2019ex\u00e9cution de chaque requ\u00eate et envoi de ces informations vers un syst\u00e8me de monitoring.\n- rate limiting\n- filtrage IP\n- d\u00e9tection de comportements suspects.\n- uniformisation des erreurs\n\nL\u2019un des objectifs de LightREST est de proposer une solution simple \u00e0 utiliser pour les d\u00e9veloppeurs WinDev, tout en offrant des capacit\u00e9s avanc\u00e9es pour les architectures plus exigeantes. Le m\u00e9canisme de hooks s\u2019inscrit dans cette philosophie.\n\nPour les usages simples, les d\u00e9veloppeurs peuvent se contenter de d\u00e9clarer des routes REST et d\u2019\u00e9crire leurs proc\u00e9dures m\u00e9tier.\nMais lorsque les besoins \u00e9voluent, les hooks permettent d\u2019ajouter progressivement des fonctionnalit\u00e9s plus avanc\u00e9es sans remettre en cause l\u2019architecture existante. Cette approche offre un excellent compromis entre simplicit\u00e9 initiale et extensibilit\u00e9 \u00e0 long terme.\n\nLe m\u00e9canisme de hooks de LightREST constitue un \u00e9l\u00e9ment cl\u00e9 de son architecture interne. En introduisant des points d\u2019extension dans le pipeline de traitement des requ\u00eates, il permet de g\u00e9rer efficacement les pr\u00e9occupations transverses qui apparaissent dans toute API professionnelle.\n\nAu-del\u00e0 de sa simplicit\u00e9 d\u2019utilisation, LightREST offre ainsi une base solide pour construire des API robustes, extensibles et adapt\u00e9es aux exigences des environnements professionnels.<\/code><\/pre>\n\n\n\n
    <\/p>\n","protected":false},"excerpt":{"rendered":"
    LightREST est un composant gratuit et open source est destin\u00e9 aux d\u00e9veloppeurs WinDev\u00ae souhaitant cr\u00e9er un Web Service REST (REpresentational State Transfer). Contrairement au syst\u00e8me propos\u00e9 nativement par WinDev\u00ae, LightREST ne n\u00e9cessite ni l\u2019installation d\u2019un serveur Web (IIS, Apache, \u2026) ni l’acquisition et les mises \u00e0 jour d’un serveur WebDev\u00ae. Les requ\u00eates API REST sont […]<\/p>\n","protected":false},"author":2,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"footnotes":""},"class_list":["post-182","page","type-page","status-publish","hentry"],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/lightrest.codeline.fr\/index.php\/wp-json\/wp\/v2\/pages\/182","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/lightrest.codeline.fr\/index.php\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/lightrest.codeline.fr\/index.php\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/lightrest.codeline.fr\/index.php\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/lightrest.codeline.fr\/index.php\/wp-json\/wp\/v2\/comments?post=182"}],"version-history":[{"count":184,"href":"https:\/\/lightrest.codeline.fr\/index.php\/wp-json\/wp\/v2\/pages\/182\/revisions"}],"predecessor-version":[{"id":2699,"href":"https:\/\/lightrest.codeline.fr\/index.php\/wp-json\/wp\/v2\/pages\/182\/revisions\/2699"}],"wp:attachment":[{"href":"https:\/\/lightrest.codeline.fr\/index.php\/wp-json\/wp\/v2\/media?parent=182"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}