SIGMAG - N°33 - Juin 2022 - 50

PERSPECTIVES
EN DEV, QU'EST-CE QUE LE « REST » ?
SI VOUS VOUS ORIENTEZ VERS DES WEBSERVICES D'ENVIRONNEMENT ARCGIS, VOUS CONSOMMEREZ UNE API REST.
AVEC CE PETIT MOT « REST », VOUS LIREZ DANS LES URL D'ACCÈS AUX DONNÉES. DÉCRYPTAGE.
REST pour « Representational State Transfer » est en résumé basé
sur la représentation directe des données. Les fonctionnalités
exposées ne produisent pas des transactions, mais interrogent des
ressources pour représenter l'état des données. Pour respecter les
règles de l'art, on produira une API RESTful qui nécessite quelques
notions particulières par rapport à d'autres types d'API.
Il y a tout d'abord la notion de Client-Serveur. C'est un « serveur »
distant qui met à disposition via un protocole http une API
consommée par une application « client ». Évident, obligatoire.
La grande notion d'uniformité. Chaque appel à l'API doit avoir
la même forme, produire le même comportement et répondre
toujours de la même manière. Elle inclut l'URI (Unique Ressource
Identifier) de la requête http. Par exemple http://api.monsig.com/
buildings pour avoir la liste des bâtiments. /buildings/1 pour le
bâtiment n°1, ou encore /buildings/1/floors/1 pour les détails du
1er étage. Elle inclut les méthodes http pour les actions : GET,
POST, PUT, DELETE. Pour illustrer, GET /entités retourne toutes
les géodonnées. GET /entités/1 retourne les détails de l'entité avec
l'id n°1. POST sert à créer une nouvelle entité, PUT aux mises à jour,
et DELETE pour effacer. Chaque appel http à l'API REST ne visera
que la ressource en question et n'effectuera pas de transactions.
Pour reproduire une transaction, il faudra enchainer les fonctions
GET, puis POST ou PUT.
Le développeur de l'API sera attentif à l'idempotence de ces
fonctions ! Une même fonction répétée plusieurs fois avec les
mêmes paramètres ne changera qu'une fois l'état des données. Le
code de retour peut changer si on tente de supprimer plusieurs fois
la même donnée, mais pas l'état des données.
Le corps de la requête se nomme parfois « payload ». Il contient
les données structurées transmises. Votre développeur dira qu'il
faut modifier le payload dans le POST de l'API RESTful ; on se
comprend ! Il sera souvent au format JSON. On peut aussi avoir
plusieurs formats dans un même payload si vous les définissez dans
les en-têtes Content-Type et Accept. Justement, les en-têtes sont
les métadonnées de votre API. On y passera aussi des informations
SIGMAG
50
d'authentification ou encore de langue. Cette uniformité impose
enfin le « code de status ». Chaque opération effectuée par l'API
doit répondre un code de status http le plus explicite possible. On
retrouve le code 200 pour une opération avec succès, 404 pour une
ressource introuvable, etc. On évitera de répondre un code 200 avec
un message du type « erreur no xxx... » !
La notion Stateless (sans-état) signifie qu'aucune information
n'est conservée sur le serveur entre deux appels successifs à l'API.
Par exemple pour l'authentification, si une session utilisateur est
maintenue sur le serveur, c'est un mode stateful. En stateless, on
passera un jeton (token) et toute autre donnée nécessaire à chaque
requête http. Cela permet de déployer facilement une API sur
plusieurs machines ou faire du scaling automatisé.
La contrainte de mise en cache est nécessaire pour optimiser
les performances au niveau de la récupération des données.
Une même requête http avec fonction GET exécutée plusieurs
fois devrait accéder aux données en cache plutôt qu'interroger
systématiquement la ressource. Évoquons rapidement le système
à plusieurs niveaux. Si l'API tourne derrière d'autres composants
comme un serveur de cache, un proxy, un répartiteur de charge, etc.
Le client qui exécute les requêtes ne doit pas y voir de différence.
Si vous êtes DE nouveaux développeurs d'API REST au lieu de SOAP,
ces éléments devraient rapidement s'incruster dans vos habitudes.
Si vous êtes consommateur d'API REST dans vos applications, ou
exploitant d'un environnement SIG, vous verrez d'un autre œil ce
grand nombre de lignes de codes pour
sélectionner et mettre à jour une entité
géographique là où d'autres systèmes
le réalisent en un appel http avec une
transaction. L'avantage du REST est
de maitriser en détail l'exécution de
nos flux tout en étant scalable, léger et
performant sur le cache.
DANIEL RIBEIRO
DIRECTEUR DE GEODATASOLUTIONS

SIGMAG - N°33 - Juin 2022

Table des matières de la publication SIGMAG - N°33 - Juin 2022