<\/p>\n\n\n\n
D\u00e9velopper une API REST ne consiste pas seulement \u00e0 exposer des routes HTTP qui renvoient des donn\u00e9es. D\u00e8s qu\u2019une API devient accessible sur un r\u00e9seau \u2014 et plus encore sur Internet \u2014 elle devient imm\u00e9diatement une surface d\u2019attaque potentielle, un point d\u2019entr\u00e9e pour des comportements impr\u00e9vus, ou un vecteur de surcharge involontaire.<\/p>\n\n\n\n
Avec LightREST<\/strong>, il est tr\u00e8s simple de cr\u00e9er rapidement un serveur REST performant. Mais cette simplicit\u00e9 ne doit jamais faire oublier que l\u2019on d\u00e9veloppe un composant serveur concurrent<\/strong>, capable de traiter plusieurs requ\u00eates simultan\u00e9ment, parfois provenant de clients inconnus ou malveillants. Ce qui est valable quelle que soit la technologie ou le protocole de communication utilis\u00e9s.<\/p>\n\n\n\n Dans ce contexte, la prudence n\u2019est pas une option. Un d\u00e9veloppeur d\u2019API doit adopter une approche presque parano\u00efaque<\/strong> : consid\u00e9rer que toute entr\u00e9e peut \u00eatre invalide, que toute ressource peut \u00eatre sollicit\u00e9e en parall\u00e8le, et que tout comportement inattendu finira un jour par se produire en production.<\/p>\n\n\n\n Une API publique doit \u00eatre con\u00e7ue pour r\u00e9sister \u00e0 :<\/p>\n\n\n\n C\u2019est pr\u00e9cis\u00e9ment pour cette raison qu\u2019il est essentiel d\u2019appliquer un ensemble de bonnes pratiques<\/strong> lors du d\u00e9veloppement d\u2019un serveur LightREST. Ces pratiques permettent de construire des API plus robustes, plus s\u00fbres et plus maintenables dans le temps.<\/p>\n\n\n\n Les recommandations pr\u00e9sent\u00e9es ci-dessous ne sont pas de simples conseils de style. Elles correspondent aux principes fondamentaux de conception des services REST modernes : gestion correcte de la concurrence, isolation des requ\u00eates, validation syst\u00e9matique des entr\u00e9es, ma\u00eetrise des ressources et respect des conventions d\u2019architecture.<\/p>\n\n\n\n Adopter ces pratiques d\u00e8s le d\u00e9part permet d\u2019\u00e9viter des probl\u00e8mes difficiles \u00e0 diagnostiquer en production et garantit que votre serveur LightREST restera stable, s\u00e9curis\u00e9 et performant, m\u00eame lorsque la charge ou l\u2019exposition publique augmentera.<\/p>\n\n\n\n LightREST est un serveur REST concurrent. Une m\u00eame route peut \u00eatre ex\u00e9cut\u00e9e simultan\u00e9ment par plusieurs requ\u00eates.<\/p>\n\n\n\n Les principes fondamentaux sont :<\/p>\n\n\n\n Une connexion base de donn\u00e9es unique, partag\u00e9e entre toutes les routes, est une mauvaise pratique en environnement serveur concurrent.<\/p>\n\n\n\n Cela peut provoquer :<\/p>\n\n\n\n M\u00eame si le handler LightREST est ex\u00e9cut\u00e9 dans un contexte Hyperfile d\u00e9die, la bonne pratique consiste \u00e0 ouvrir la connexion pour chaque requ\u00eate \u00e0 a y affecter les tables de l\u2019analyse, g\u00e9n\u00e9ralement via un hook ex\u00e9cut\u00e9 avant le handler, puis \u00e0 la fermer dans un hook de fin. Les moteurs de base de donn\u00e9es g\u00e9rant des pools de connexions disponibles, le processus est tr\u00e8s rapide.<\/p>\n\n\n\n Exemple :<\/strong><\/p>\n\n\n\n Copier<\/p>\n\n\n\n Puis dans le handler :<\/p>\n\n\n\n Copier<\/p>\n\n\n\n Dans LightREST, plusieurs requ\u00eates peuvent acc\u00e9der au m\u00eame moment au m\u00eame code et aux m\u00eames donn\u00e9es.<\/p>\n\n\n\n Une variable globale non prot\u00e9g\u00e9e peut donc devenir une source :<\/p>\n\n\n\n Exemple \u00e0 \u00e9viter :<\/strong><\/p>\n\n\n\n Copier<\/p>\n\n\n\n Si un \u00e9tat partag\u00e9 est r\u00e9ellement n\u00e9cessaire, il doit \u00eatre prot\u00e9g\u00e9 par un m\u00e9canisme de synchronisation ou stock\u00e9 dans une structure adapt\u00e9e.<\/p>\n\n\n\n LightREST fournit les membres CustomData<\/strong> \u00e0 plusieurs niveaux :<\/p>\n\n\n\n C\u2019est la m\u00e9thode recommand\u00e9e pour associer des donn\u00e9es de contexte sans multiplier les variables globales dispers\u00e9es.<\/p>\n\n\n\n Exemple :<\/strong><\/p>\n\n\n\n Copier<\/p>\n\n\n\n Puis dans le handler :<\/p>\n\n\n\n Copier<\/p>\n\n\n\n Le plus s\u00fbr est d\u2019\u00e9viter ce cas de figure. Si toutefois c\u2019est incontournable, il faut que leur acc\u00e8s soit ma\u00eetris\u00e9.<\/p>\n\n\n\n Toute ressource partag\u00e9e doit \u00eatre :<\/p>\n\n\n\n Par exemple, si plusieurs handlers modifient un m\u00eame compteur ou une m\u00eame structure, il faut s\u00e9curiser l\u2019acc\u00e8s par section critique (https:\/\/doc.pcsoft.fr\/fr-FR\/?1000021292<\/u><\/a>), s\u00e9maphore (https:\/\/doc.pcsoft.fr\/fr-FR\/?3077013<\/u><\/a>) ou autre m\u00e9canisme appropri\u00e9.<\/p>\n\n\n\n Copier<\/p>\n\n\n\n Exposer directement un identifiant base de donn\u00e9es dans une URL facilite :<\/p>\n\n\n\n Exemple \u00e0 \u00e9viter :<\/strong><\/p>\n\n\n\n Copier<\/p>\n\n\n\n Il est pr\u00e9f\u00e9rable d\u2019exposer un identifiant chiffr\u00e9 ou obfusqu\u00e9 via les fonctions :<\/p>\n\n\n\n Exemple :<\/strong><\/p>\n\n\n\n Copier<\/p>\n\n\n\n Puis dans le handler :<\/p>\n\n\n\n Copier<\/p>\n\n\n\n Oui. Une API REST doit rester aussi stateless que possible.<\/p>\n\n\n\n Une requ\u00eate ne doit pas d\u00e9pendre d\u2019un \u00e9tat conserv\u00e9 implicitement dans le serveur ou dans un handler pr\u00e9c\u00e9dent.<\/p>\n\n\n\n Il faut \u00e9viter par exemple :<\/p>\n\n\n\n Chaque requ\u00eate doit porter elle-m\u00eame les informations n\u00e9cessaires via :<\/p>\n\n\n\n Un handler REST doit r\u00e9pondre rapidement.<\/p>\n\n\n\n Un traitement long monopolise inutilement les ressources du serveur et d\u00e9grade la capacit\u00e9 \u00e0 traiter d\u2019autres requ\u00eates. Exemple de r\u00e9ponse :<\/strong><\/p>\n\n\n\n Copier<\/p>\n\n\n\n Centraliser l\u2019authentification avec un Hook EVE_BEFORE_HANDLER \u00e9vite la duplication de code dans chaque route et r\u00e9duit le risque d\u2019oublis ou d\u2019incoh\u00e9rences.<\/p>\n\n\n\n La fonction d\u00e9di\u00e9e permet d\u2019appliquer une logique homog\u00e8ne sur l\u2019ensemble du serveur ou sur un groupe de routes.<\/p>\n\n\n\n Copier<\/p>\n\n\n\n Une authentification centralis\u00e9e am\u00e9liore :<\/p>\n\n\n\n Une API en production doit permettre de comprendre ce qu\u2019il se passe en cas d\u2019erreur, de lenteur ou d\u2019usage anormal.<\/p>\n\n\n\n Il faut journaliser au minimum :<\/p>\n\n\n\n Hooks utiles :<\/strong><\/p>\n\n\n\n Retourner des volumes massifs de donn\u00e9es ralentit :<\/p>\n\n\n\n Il est pr\u00e9f\u00e9rable d\u2019utiliser :<\/p>\n\n\n\n Copier<\/p>\n\n\n\n Cette pratique am\u00e9liore \u00e0 la fois les performances et l\u2019exp\u00e9rience d\u2019int\u00e9gration c\u00f4t\u00e9 client.<\/p>\n\n\n\n Un bon d\u00e9veloppeur d\u2019API se doit d\u2019\u00eatre PARANO\u00cfAQUE ! Une API ne doit jamais faire confiance aux donn\u00e9es re\u00e7ues.<\/p>\n\n\n\n Il faut valider :<\/p>\n\n\n\n Copier<\/p>\n\n\n\n C\u2019est tr\u00e8s important pour une API publique<\/strong>.<\/p>\n\n\n\n Une API ne doit jamais renvoyer directement des erreurs internes du serveur ou de la base de donn\u00e9es, qui peuvent contenir des extraits de code, le contenu de variables, des requ\u00eates SQL ou des donn\u00e9es.<\/p>\n\n\n\n Exemples dangereux :<\/p>\n\n\n\n Copier<\/p>\n\n\n\n Ces informations peuvent r\u00e9v\u00e9ler :<\/p>\n\n\n\n La bonne pratique consiste \u00e0 renvoyer des messages d\u2019erreur contr\u00f4l\u00e9s.<\/p>\n\n\n\n Exemple :<\/p>\n\n\n\n Copier<\/p>\n\n\n\n Les d\u00e9tails techniques doivent \u00eatre enregistr\u00e9s uniquement dans les logs serveur. Tr\u00e8s utilis\u00e9 en production.<\/p>\n\n\n\n Un serveur API devrait exposer une route simple permettant de v\u00e9rifier son \u00e9tat.<\/p>\n\n\n\n Exemple :<\/p>\n\n\n\n Copier<\/p>\n\n\n\n R\u00e9ponse :<\/p>\n\n\n\n Copier<\/p>\n\n\n\n Ce type de route est utilis\u00e9 par :<\/p>\n\n\n\n Une API coh\u00e9rente r\u00e9duit la documentation n\u00e9cessaire et facilite l\u2019adoption.LightREST V3 marque une \u00e9volution majeure : plus ouvert<\/strong>, plus flexible<\/strong>, plus s\u00e9curis\u00e9<\/strong>, et plus robuste en production<\/strong>. <\/p>\n","protected":false},"excerpt":{"rendered":" \u00catre parano\u00efaque ! D\u00e9velopper une API REST ne consiste pas seulement \u00e0 exposer des routes HTTP qui renvoient des donn\u00e9es. D\u00e8s qu\u2019une API devient accessible sur un r\u00e9seau \u2014 et plus encore sur Internet \u2014 elle devient imm\u00e9diatement une surface d\u2019attaque potentielle, un point d\u2019entr\u00e9e pour des comportements impr\u00e9vus, ou un vecteur de surcharge involontaire. […]<\/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-2679","page","type-page","status-publish","hentry"],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/lightrest.codeline.fr\/index.php\/wp-json\/wp\/v2\/pages\/2679","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=2679"}],"version-history":[{"count":13,"href":"https:\/\/lightrest.codeline.fr\/index.php\/wp-json\/wp\/v2\/pages\/2679\/revisions"}],"predecessor-version":[{"id":2701,"href":"https:\/\/lightrest.codeline.fr\/index.php\/wp-json\/wp\/v2\/pages\/2679\/revisions\/2701"}],"wp:attachment":[{"href":"https:\/\/lightrest.codeline.fr\/index.php\/wp-json\/wp\/v2\/media?parent=2679"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}\n
\n
\n\n\n\nPas de connexion base de donn\u00e9es globale<\/h2>\n\n\n\n
\n
PROC\u00c9DURE HookBeforeMethod(pEventInfo lrHook:EventInfo) : lrHook:EventReturn\n\ncnxDB est une Connexion\n\n\/\/d\u00e9finir les param\u00e8tres de la connexion......\n\nSI PAS HOuvreConnexion(cnxDB ) ALORS\n pEventInfo:Response:Status = lrResponse::StatusInternalServerError\n pEventInfo:Response:ContentType = lrReponse::ContentTXT\n pEventInfo:Response:Body = Herreuurinfo()\n RENVOYER lrHook:EVE_ABORT\nFIN\n \npRequest:DatabaseConnexion[\"DB\"] = cnxDB \nhChangeConnexion(\"*\", cnxDB )\n\nRENVOYER lrHook:EVE_OK\n<\/code><\/pre>\n\n\n\nPROC\u00c9DURE HookAfterMethod(pEventInfo lrHook:EventInfo) : lrHook:EventReturn\n\nSI pRequest:DatabaseConnexion[\"DB\"]..existe ALORS\n hFermeConnexion(pRequest:DatabaseConnexion[\"DB\"])\nFIN\nRENVOYER lrHook:EVE_OK\n<\/code><\/pre>\n\n\n\n
\n\n\n\n\u00c9viter les variables globales dans les handlers<\/h2>\n\n\n\n
\n
gCompteur++\n<\/code><\/pre>\n\n\n\n
\n\n\n\nPartager proprement des donn\u00e9es globales avec LightREST<\/h2>\n\n\n\n
\n
oServer:CustomData[\"Config\"] = maConfiguration\n<\/code><\/pre>\n\n\n\ncfg est un Config = poRequest:ServerCustomData[\"Config\"]\n<\/code><\/pre>\n\n\n\n
Cette approche rend le code plus clair, mieux structur\u00e9 et plus s\u00fbr.<\/p>\n\n\n\n
\n\n\n\nLimiter l\u2019utilisation des objets ou ressources partag\u00e9s entre plusieurs handlers<\/h2>\n\n\n\n
\n
SectionCritiqueD\u00e9but(gsLock)\ngCompteur++\nSectionCritiqueFin(gsLock)\n<\/code><\/pre>\n\n\n\n
\n\n\n\nNe pas exposer les identifiants techniques dans les routes<\/h2>\n\n\n\n
\n
GET \/clients\/1287\n<\/code><\/pre>\n\n\n\n\n
CipherID()<\/code><\/li>\n\n\n\nDecipherID()<\/code>
NB : L\u2019algorithme CiphedID ne produira pas le m\u00eame identifiant chiffr\u00e9 pour 2 valeurs identiques sur 2 tables diff\u00e9rentes.<\/li>\n<\/ul>\n\n\n\nGET \/clients\/03980608-5abe9581-7fee65e9-194ae106\n<\/code><\/pre>\n\n\n\nnID est entier = DecipherID(pRequest:GetUrlValue(\"id\"))\n\n\/\/Ici nID = 1287\n<\/code><\/pre>\n\n\n\n
\n\n\n\nRester stateless<\/h2>\n\n\n\n
\n
\n
\n\n\n\n\u00c9viter les variables globales dans les handlers<\/h2>\n\n\n\n
A partir de la version 3.3, LightREST propose un syst\u00e8me de Workers qui permettent d\u2019ex\u00e9cution des traitements longs de fa\u00e7on asynchrone et de lib\u00e9rer imm\u00e9diatement le handler en cours.
Il est pr\u00e9f\u00e9rable de :<\/p>\n\n\n\n\n
{\n \"status\": \"accepted\",\n \"jobId\": \"12345\"\n}\n<\/code><\/pre>\n\n\n\n
\n\n\n\nCentraliser l\u2019authentification<\/h2>\n\n\n\n
SetAuthenticationCheckFunction()\n<\/code><\/pre>\n\n\n\n\n
\n\n\n\nCentraliser les logs<\/h2>\n\n\n\n
\n
\n
EVE_ERROR<\/code><\/li>\n\n\n\nEVE_WARNING<\/code><\/li>\n\n\n\nEVE_AUTH_FAILED<\/code><\/li>\n\n\n\nEVE_RECEIVED<\/code><\/li>\n<\/ul>\n\n\n\n
\n\n\n\nLimiter le volume des r\u00e9ponses<\/h2>\n\n\n\n
\n
\n
GET \/clients?page=1&limit=50\n<\/code><\/pre>\n\n\n\n
\n\n\n\nValider syst\u00e9matiquement les entr\u00e9es<\/h2>\n\n\n\n
\n
sID = pRequest:GetUrlValue(\"id\")\n\nSI sID = \"\" ALORS\n oResponse:Status = lrResponse::StatusBadRequest\nFIN\n<\/code><\/pre>\n\n\n\n
\n\n\n\nNe jamais exposer le d\u00e9tail des erreurs techniques<\/h2>\n\n\n\n
SQL error near column CLIENT_ID
File not found: \/var\/data\/config.ini
Stack trace...<\/pre>\n\n\n\n\n
{
\"error\": \"internal_error\",
\"message\": \"An unexpected error occurred\"
}<\/pre>\n\n\n\n
NB : Le niveau de d\u00e9tail des erreurs g\u00e9r\u00e9es automatiquement par LightREST est r\u00e9glable par la propri\u00e9t\u00e9 lrServer:WindevErrorDetail.<\/p>\n\n\n\n
\n\n\n\nAjouter un endpoint de sant\u00e9 (health check)<\/h2>\n\n\n\n
GET \/health<\/pre>\n\n\n\n
{
\"status\": \"ok\"
}<\/pre>\n\n\n\n\n
\n\n\n\nRespecter les conventions REST<\/h2>\n\n\n\n
Action<\/th> Route<\/th><\/tr> liste<\/td> GET \/clients<\/td><\/tr> d\u00e9tail<\/td> GET \/clients\/{id}<\/td><\/tr> cr\u00e9ation<\/td> POST \/clients<\/td><\/tr> modification<\/td> PUT \/clients\/{id}<\/td><\/tr> suppression<\/td> DELETE \/clients\/{id}<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Cette page r\u00e9capitule les nouveaut\u00e9s principales et surtout ce qu\u2019elles apportent concr\u00e8tement<\/strong> au quotidien.
<\/p>\n\n\n\n
\n\n\n\n