API REST

Comprendre les API REST, leurs spécificités et comment consommer,

développer une API RESTful avec les meilleurs standards de
performance, de scalabilité et de sécurité.

Professeur : AGBAVON Kokou Bienvenu

Université : Collège de Paris
Classe : B2 – IT
Dernière Mise à Jour : 03 Mars 2024
Objectifs du cours :

A la fin de ce cours, l’étudiant devra être en mesure de :

• Expliquer les concepts fondamentaux d’une API REST : ressources,
représentations, URIs, méthodes HTTP.
• Expliquer les différences entre une API REST, et les autres types d’APIs.
• Utiliser les méthodes et objets HTTP appropriées pour interagir avec les
ressources d'une API REST.
• Connaitre les principes de base de la sécurité des API REST et expliquer les
enjeux de sécurité liés aux API REST.
D’un point de vue pratique, l’étudiant devra être en mesure également de :
• Utiliser les outils et les frameworks populaires pour la configuration, le
développement, le test et la documentation d'API REST, avec les méthodes
HTTP et les représentations.
• Consommer des API REST existantes pour intégrer des fonctionnalités
externes dans une application.
• Planifier, concevoir et implémenter une API REST pour un projet personnel ou
professionnel, dans un scénario d’application spécifique.
• Créer un diagramme d’état d’une API et écrire un cahier de charges de l’API.
• Savoir utiliser différents outils pour tester les API REST et documenter les API
REST avec Swagger, OpenAPI ou autres outils.
• Mettre en place des mesures de sécurité, y compris l’authentification et
l'autorisation et savoir protéger les API REST contre les attaques.
Prérequis :

Pour être en mesure de suivre et comprendre aisément le contenu du cours, il est

recommandé que les étudiants aient des notions de bases dans les thématiques
suivantes :
• Fonctionnement du développement Web, avec HTML, CSS, JavaScript.
• Fonctionnement des protocoles TCP/IP, HTTP, et HTTPS.

Pour être en mesure de mettre en pratique les concepts appris, il est recommandé
que les étudiants aient des :
• Connaissance dans un langage de programmation orienté objet, permettant
de développer des API.
• Connaissance de base en bases de données (Bases de Données
relationnelles et non relationnelles, les tables, clés primaires).
Programme du cours :

1. Introduction aux API REST

a. Définitions et concepts clés : ressources, représentations, URIs
b. Contraintes et principes d’architecture
c. Comparaison avec une autre architecture d’API : SOAP
d. Avantages et inconvénients
2. Interagir avec une API REST via HTTP
a. Requête HTTP
b. Réponse HTTP
c. Sécurisation d’une API REST
3. TP : Tester une API avec POSTMAN, Comprendre et analyser la
documentation (Cas de Paygate Global).
4. Conception d’une API REST
a. Cahier des charges
b. Documentation
5. Développement d’une API REST
a. Choix des outils de création
i. Language
ii. Framework
iii. Base de données
iv. Outil de Test
b. Configuration des méthodes HTTP
c. Définition des ressources, des URI et de leur représentation
d. Interception et validation des requêtes
e. Traitement et réponses
f. Gestion des erreurs et des exceptions.
g. Sécurité
i. Authentification et autorisation.
ii. Protection contre les attaques.
h. Test et débogage
6. Aller plus loin dans la conception d’une API REST
a. Quelques recommandations
b. Optimisation de la performance
Evaluation :
• Contrôle(s) continu(s) (TD ou TP) - 50% de la note finale.
• Examen final ou Projet Final – 50% de la note finale.

L’étudiant est encouragé à :

• Participer activement au cours ;
• Prendre des initiatives, poser des questions pour approfondir les explications ;
• Continuer l’apprentissage en dehors des heures de cours et continuer les
travaux pratiques initiés en classe.
Documentation :

• "REST API Design Rulebook" de Mark Masse

• “Pro RESTful APIs” de Sanjay Patni
• "APIs : A Strategy Guide" de Daniel Jacobson
• "RESTful Web APIs" de Leonard Richardson, Mike Amundsen, and Sam Ruby
• "Building Microservices" de Sam Newman

Toute la documentation est accessible sur ce lien, plus en supplément quelques

autres livres pour ceux et celles qui souhaitent aller plus loin.
 INTRODUCTION
Tous les systèmes d’informations envoient et reçoivent de la donnée (XML, JSON,
Binaire, Texte, …). Il existe donc différents protocoles (HTTP, FTP, SMTP, …) qui
définissent les standards communs à respecter lors de l’envoi et de la réception de
ces données à travers le réseau.

Les systèmes applicatifs doivent pouvoir communiquer efficacement tout

en garantissant la propriété intellectuelle de leur fonctionnement interne. C’est l’un
des rôles majeurs des Application Programming Interface (API) : fournir une
méthodologie, un contrat clair permettant l’interconnexion de différentes applications.

Différentes architectures d’API existent qui définissent les contraintes à respecter par
ces systèmes durant leur communication. L’architecture la plus utilisée aujourd’hui
est le Representational State Transfer, en abrégé REST.

Ce cours, va introduire et approfondir les différentes notions et contraintes

architecturaux des API REST. Au travers des travaux pratiques, il permettra une
compréhension de leur fonctionnement et fournira les outils et connaissances
nécessaires pour concevoir et développer une API REST sécurisée.
 Chapitre 1
Introduction aux API REST
 A) Définitions et concepts clés

Un système d’information est un ensemble d’instructions informatiques, écrites

dans un langage de programmation capable de recevoir des données en entrée,
d’effectuer des traitements, de faire appel à d’autres systèmes d’informations et de
transmettre une réponse.

Pour faciliter les échanges de données, le système fournisseur d’informations met à

disposition des autres systèmes (demandeurs), une collection d’informations qui leur
indique toutes les données qu’il peut transmettre et comment lui faire la demande
pour qu’il transmette la bonne donnée : c’est la documentation de son interface
d’échange de données.
Une API (Application Programming Interface) est donc un moyen par lequel deux
ou plusieurs programmes informatiques communiquent. Le programme initiateur de
la communication, demande une information précise, en fournissant un ensemble
d’informations détaillant le type (format) et le contenu de la réponse attendue. Cette
demande, appelée requête, est soumis au programme récepteur / traiteur via un
protocole (cf. Les couches du modèle OSI) : dans ce contexte, le programme
initiateur est appelé un client.
Exemples d’API :
• API Google Maps : L'API Google Maps permet aux développeurs d'accéder
aux données cartographiques et de les intégrer dans leurs propres
applications.
• API PayPal : L'API PayPal permet aux développeurs de traiter les paiements
et de gérer les transactions financières.

Après traitement de la requête, le programme récepteur / traiteur, appelé serveur,

transmet au client via le même protocole une information, dont le contenu et le format
est conforme ou non à celui attendu par le client.

Figure 1 - Echange Client-Serveur

Le client et le serveur sont généralement en exécution sur des machines différentes,
connectées au travers d’un réseau. Il existe différents types d’échanges client-
serveur.

Serveur - Client Usages Exemples

Mail Envoi et Réception de Mails Gmail, Outlook
Location d’espace de
De Ressources stockage, de RAM, de GeForce Now, Shadow
puissance de calcul (CPU).
Naviguer sur le WWW grâce
Web Chrome, Safari, Firefox
à un réseau Internet.
Accès et maintenance d’une PostGreSQL & pgAdmin,
De Base de données collection de données au MySQL & MySQL
travers d’un réseau. Workbench
Stockage, Envoi, Réception
Fichier de fichiers à travers un Drive, OneDrive
réseau.

Héberge le code des

Client internet/http,
applications back end,
D’application TomCat, Bun, NodeJS,
accessible au travers d’un
Deno, .NET
réseau.

Tableau 1 - Types et exemples d'échanges client - serveur.

Maintenant que les notions de systèmes d’informations, d’API, de client et serveur,

de requête et réponse, de service et de service Web nous sont familières, continuons
notre entrée en matière vers les API REST.
Une API définit le fond, c’est-à-dire le contenu de l’information qui est échangé lors
de l’interaction entre un client et un serveur. Dans cet échange, l’information auquel
le client veut accéder est appelée une Ressource.
Une ressource, est une entité spécifique, qu’un serveur expose au travers de son
API. Elle peut être de différent type (objet, fichier, image, vidéo, …). Elle possède des
attributs et des actions associés. Elle est identifiée de manière unique par une
chaîne de caractères représentant le moyen d’y accéder, l’Uniform Resource
Identifier (URI).
Les URLs (Uniform Resource Locator) sont un type spécifique d’URI, faisaient
références entre autres à des ressources hébergées sur le Web et accessibles avec
des navigateurs via Internet ou un Intranet.
Après avoir analysé la demande, le serveur envoie une représentation de la
ressource demandée. Une représentation, est une forme ou une organisation des
données qui représente l’état actuel de la ressource. Elle sera transmise entre le
client et le serveur et peut se présenter sous différents formats tels que : JSON,
XML, HTML, texte brut, etc.

Pour communiquer efficacement le client et le serveur se mettent d’accord sur un

standard, qui définit le type et le format de leurs échanges. L’architecture ou le type
de l’API, définit la forme que doivent prendre ces échanges de données. Elle établit
les contraintes à respecter par le client et le serveur lors de la communication, pour
faciliter la compréhension et la transmission des données.
En résumé, le client identifie les ressources exposées par le serveur au travers de
l’API et de la documentation fournit par ce dernier. Pour accéder à une ressource de
ce serveur, il fait une demande sur l’URI correspondante à cette ressource. Le format
de la requête transmise et de la réponse attendue est défini par l’architecture de
l’API. Le dernier inconnu de cet échange est le moyen la requête émise par le client
est acheminé vers le serveur, et vice-versa.
L’architecture d’une API se base sur un ou plusieurs protocoles de communication,
dont le rôle est d’acheminer la requête, du client vers le serveur et la réponse du
serveur vers le client.

Pour illustrer tout cela, faisons une analogie entre les échanges client, serveur et la
commande d’un plat dans un restaurant :
• Vous êtes un client dans un restaurant et vous souhaitez commander un plat.
• Le menu du restaurant est alors L’API. Elle définit les plats disponibles, les
variétés, les ingrédients, les prix et les options de personnalisation.
• Vous choisissez votre plat ; et vous avez besoin de communiquer votre choix
à un serveur (personnel du restaurant, serveurs et cuisiniers). Vous allez alors
utiliser un protocole de communication (langue parlée ou écrite) pour
 transmettre votre choix. Ce protocole définit des spécifications d’entrée
(formules de politesse), un vocabulaire (j’aimerai commander en entrée…).
• A la réception de votre commande, avant de le transmettre au cuisiner, le
serveur va l’agrémenter d’informations (d’en tête), permettant plus tard
d’identifier le destinataire (c’est-à-dire vous) du plat, donc de sécuriser la
demande du client. Il transmet (transporte) ensuite votre commande au
cuisinier à l’aide de notes codifiées inscrites sur un papier.
• Le cuisinier finit de préparer votre commande, fait appel au serveur, lui remet
la note initiale et le repas.
• Le serveur transporte votre repas, et sa note initiale qui lui permet de vous
retrouver facilement dans le restaurant, parmi les autres clients.
• Il vous transmet le repas, s’assure que vous êtes satisfait, et peux alors
répondre aux demandes d’autres clients. Si vous n’êtes pas satisfaits, vous
pouvez lui indiquer les corrections à effectuer et le processus recommence.

Dans cette analogie, vous êtes le client, le restaurant et son personnel le serveur, le
style architectural et le type de plat servi par le restaurant son type ou architecture
d’API, la langue le protocole de communication, et les repas la ressource servi par
ce serveur.

Le décor est posé. Dans la suite nous allons approfondir les différentes thématiques
abordées.
Une API est une interface facilitant les échanges entre différents logiciels. Cet
échange entre le client et le serveur est appelé un échange de service. Lorsque le
serveur est hébergé en ligne et accessible via Internet (protocole TPC / IP – couche
Transport du modèle OSI), on parle de service Web. Par extension, un service Web
désigne également le serveur en exécution qui reçoit des requêtes au travers d’un
réseau et qui fournit en réponse des documents Web (HTML, JSON, XML, fichiers,
…).
L’architecture ou le type de l’API, par extension celui du service Web, définit la forme
que doivent prendre les échanges de données. Elle établit les contraintes à respecter
par le client et le serveur lors de la communication, pour faciliter la compréhension et
la transmission des données.
Les deux architectures des services Web les plus répandues aujourd’hui sont :
• REST : REpresentational State Transfer.
• SOAP : Simple Object Access Protocol.

Ces deux architectures se basent essentiellement sur le protocole HTTP pour définir
les formats d’échanges de données.
En résumé :
• Une API est une interface facilitant les échanges entre différents logiciels.
• Un service Web est une API, hébergée sur un serveur, accessible au travers
d’Internet et des protocoles standard du Web.
• REST et SOAP sont les deux styles d’architectures des services Web les plus
utilisés aujourd’hui.
• HTTP est le protocole de transport utilisé pour transférer des données sur le
Web.

Dans la suite du cours, nous détaillerons les particularités et contraintes de

l’architecture REST ; ensuite nous effectuerons une comparaison avec l'architecture
SOAP, qui nous permettra d’identifier les avantages et inconvénients des différentes
approches.

Nous détaillerons les liens et l’utilisation qui est faite du protocole HTTP dans les
échanges de données d’une API REST dans le chapitre suivant.
 B) Contraintes et principes d’architecture
L’architecture REST défini un ensemble de contraintes. Une API est dite RESTful
(qui respecte les contraintes de l’architecture REST) si elle remplit les conditions
suivantes :
• Une architecture client-serveur constituée de clients, de serveurs et de
ressources, avec des requêtes gérées via HTTP. Ce premier principe indique
essentiellement que les serveurs et les clients ne doivent connaître que les
URL des ressources et c'est tout. Il n'y a pas de dépendance. Chacun peut
être développé et remplacé indépendamment tant que l'interface entre eux
reste inchangée.
• Des communications client-serveur stateless (sans état), ce qui signifie que le
serveur ne stocke aucune information sur les requêtes qu'il reçoit et ne
maintient pas de connexion entre les appels. De ce fait, les appels sont
effectués indépendamment et chaque requête est traitée comme une première
demande, sans session ni historique. De plus, les appels doivent contenir
toutes les informations nécessaires au traitement des requêtes.
• La possibilité de mettre en cache des données (ressources) afin de
rationaliser les interactions client-serveur. Cette mise en cache peut se faire
en un ou plusieurs points au sein du client et du serveur ou entre le client et le
serveur. Pour que la réponse puisse être envoyée plus rapidement, la
ressource doit être mise en cache. Les API REST identifient les ressources
qui peuvent être mises en cache et déterminent la durée pendant laquelle
elles peuvent rester dans le cache.
Par exemple, supposons que vous visitez un site Web dont les images d'en-
tête et de pied de page sont communes à toutes les pages. Chaque fois que
vous visitez une nouvelle page du site, le serveur doit renvoyer les mêmes
images. Pour éviter cela, le client met en cache ou stocke ces images après la
première réponse et utilise ensuite les images directement depuis le cache.
• Une interface uniforme entre les composants qui permet un transfert
standardisé des informations. Elle indique que le serveur transfère les
informations dans un format standard. La ressource formatée est appelée
représentation dans REST. Ce format peut être différent de la représentation
interne de la ressource sur l'application serveur. Par exemple, le serveur peut
stocker des données sous forme de texte mais les envoyer dans un format de
représentation HTML. Cela implique que :
o Les ressources demandées soient identifiables et séparées des
représentations envoyées au client ;
o Les ressources puissent être manipulées par le client au moyen de la
représentation reçue, qui contient suffisamment d'informations ;
o Les messages autodescriptifs renvoyés au client contiennent assez de
détails pour décrire la manière dont celui-ci doit traiter les informations.
o L’API possède un hypertexte/hypermédia, qui permet au client d'utiliser
des hyperliens pour connaître toutes les autres actions disponibles
après avoir accédé à une ressource.
 • Un système à couches, invisible pour le client, qui permet d'organiser les
différents types de serveurs impliqués dans la récupération des données
requises. Les API REST comportent plusieurs couches comme des serveurs
proxy ou des dispositifs de répartition de charge. Pour envoyer une réponse,
le serveur d'extrémité peut utiliser des serveurs supplémentaires. Toutes ces
couches fonctionnent ensemble pour établir une hiérarchie permettant de
concevoir une application plus flexible. Un système en couche apporte :
o Une meilleure sécurité à une application, car il n'est pas possible pour
les composants de chaque couche de communiquer en dehors de la
couche qui suit.
o Une plus grande stabilité puisqu'il limite les performances des
composants afin que chaque composant ne puisse pas aller plus loin
que la couche suivante.
• Du code à la demande (facultatif), c'est-à-dire la possibilité d'envoyer du code
exécutable depuis le serveur vers le client (lorsqu'il le demande) afin d'étendre
les fonctionnalités d'un client (applets Java ou JavaScript).

Une représentation REST est généralement composée de trois éléments :

- Les données : les données brutes de la ressource, telles que le nom, la
description, le prix, etc.
- Les métadonnées : les informations supplémentaires sur la ressource, telles
que le type de média, la date de création, la date de modification, etc.
- Les liens : les références hypertextes vers d'autres ressources connexes,
telles que les ressources associées, les ressources enfants, etc.

Figure 2 - Exemple de représentation REST d'un Produit en JSON

 C) Comparaison avec un autre style d’architecture d’API : SOAP
SOAP (Simple Object Access Protocol, datant de 1998) est une autre approche
courante pour la conception d'API. Voici une comparaison détaillée entre cette
architecture, et l’architecture REST (datant de 2000) :
1. Style architectural :
• REST est basé sur le transfert de ressources, grâce aux méthodes HTTP
standard sous des formats de données légers pour créer des API
évolutives et interopérables.
• SOAP est basé sur l'échange de messages en XML grâce à HTTP, TCP
ou SMTP, entre des systèmes distribués (différents systèmes
interdépendants qui fonctionnent ensemble pour fournir un service). Les
messages utilisent des enveloppes, et sont structurés en en-têtes et des
corps de message pour encapsuler les données et les métadonnées
(données/annotations sur les données).
2. Format de données :
• REST utilise des formats de données légers tels que JSON, XML ou YAML
pour représenter les ressources et les données.
• SOAP utilise exclusivement XML pour représenter les données et les
métadonnées.

Figure 3 - Exemple message SOAP structuré

3. Protocoles de transport :
• REST utilise HTTP comme protocole de transport pour les échanges de
données.
• SOAP peut utiliser HTTP, SMTP ou d'autres protocoles de transport pour
l'échange de messages.
4. Interopérabilité :
 • REST est conçu pour être hautement interopérable, grâce à l'utilisation de
méthodes HTTP standard, de formats de données légers et d'une
architecture orientée ressources. Il est souvent utilisé dans les applications
Web et mobiles.
• SOAP est également conçu pour être interopérable, mais peut être plus
complexe à mettre en œuvre en raison de l'utilisation de XML. Il est
souvent utilisé dans les environnements d'entreprise pour les échanges de
données entre les applications serveurs.
5. Sécurité :
• REST utilise généralement HTTPS pour sécuriser les échanges de
données, mais peut également utiliser d'autres mécanismes de sécurité
tels que OAuth ou JWT.
• SOAP peut utiliser différents mécanismes de sécurité tels que WS-
Security, SSL/TLS ou des certificats numériques.
En résumé, REST est une architecture légère, interopérable et évolutive pour la
conception d'API et de services web, qui utilise des formats de données légers et des
méthodes HTTP standard. SOAP est un protocole plus lourd et plus complexe, conçu
pour l'échange de messages structurés entre systèmes distribués. Chaque approche
a ses avantages et ses inconvénients, et le choix dépend des besoins spécifiques de
l'application ou du service web.
SOAP est également un protocole. Cette nature est la source de la rigidité de son
implémentation.
 Tableaux comparatifs entre les APIs REST et SOAP.

Tableau comparatif suivant plusieurs critères.

Critère REST SOAP
Fonctionne grâce à l'utilisation de formats de données Moins efficace en raison de la surcharge d'analyse XML
Performance
plus légers comme JSON. et de la verbosité du format XML.

Gestion des Utilise des codes d'état HTTP standard pour la gestion Dispose d'éléments d'erreur standardisés pour la gestion
erreurs des erreurs. des erreurs.

Intégration Approche légère et flexible. Conformité stricte aux normes requises.

Quelle architecture choisir suivant mon besoin ?

Besoin Architecture à privilégier

Quand les clients ont besoin d'avoir accès aux détails sur les types
d’objets disponibles sur les serveurs (et pas uniquement à des
représentations)
SOAP : Services financiers, Passerelles de
Lorsque vous souhaitez établir un contrat rigoureux entre le client et
paiements, Services de télécommunications.
le serveur (dépendance forte)
Lors de l'exécution de transactions impliquant plusieurs appels
(chacune de ces appels étant liés)
Lorsque vous souhaitez que la majorité des développeurs utilisent
facilement votre API.
REST : Médias et Réseaux sociaux, Services de
Lorsque votre bande passante est très limitée messageries, Services destinées aux applications
mobiles & web.
Lorsque les clients et les serveurs fonctionnent dans un
environnement Web, mobile ou IoT
 D) Avantages et inconvénients

i. Avantages
Citons quelques avantages liés aux API respectant les contraintes d’architecture de
REST.
1) Evolutivité
Puisque REST est un ensemble de directives mises en œuvre à la demande, les API
REST sont plus rapides et légères, et offrent une évolutivité accrue. Elles sont donc
idéales pour l'IoT (Internet des objets) et le développement d'applications mobiles.
Les services RESTful peuvent être facilement mis à l'échelle horizontalement, car ils
sont sans état. Chaque demande d'un client contient toutes les informations
nécessaires pour répondre à cette demande, ce qui facilite la distribution et
l'équilibrage de charge.
2) Simplicité
Les API REST sont relativement simples à comprendre et à utiliser car elles suivent
les méthodes HTTP standard et utilisent des conventions standard pour la
représentation des ressources (généralement JSON ou XML).
Chaque requête d'un client vers une API REST est indépendante et sans état. Le
serveur n'a pas besoin de stocker d'informations sur le client entre les requêtes, ce
qui simplifie la conception et la mise en œuvre du client et du serveur.
3) Flexibilité
REST permet une large gamme de formats de données, mais JSON est le plus
couramment utilisé en raison de sa simplicité et de sa facilité d'analyse. Cette
flexibilité rend les API REST adaptées à différents types de clients et d'applications.
4) Mise en cache
REST prend en charge les mécanismes de mise en cache, permettant aux clients de
mettre en cache les réponses. Cela améliore les performances et réduit la charge sur
le serveur, en particulier pour les ressources qui ne changent pas fréquemment.
5) Polyvalence
Contrairement à SOAP, REST n'est pas limité à XML, mais peut renvoyer des
formats XML, JSON, HTML, PYTHON, PHP ou texte en fonction de ce que le client
demande. Contrairement à la technologie RPC, les utilisateurs ne sont pas tenus de
connaître les noms des procédures ou les paramètres spécifiques dans un ordre
précis.

La structure des API RESTful induit des inconvénients ; énumérons quelques-uns.

 II- Inconvénients
1. Récupération excessive ou insuffisante des données
Les clients peuvent recevoir plus de données que nécessaire (sur-récupération) ou
pas assez de données (sous-récupération) pour une opération particulière, ce qui
peut conduire à une utilisation inefficace de la bande passante et affecter les
performances.
2. Prise en charge limitée de la communication en temps réel
Les API RESTful sont basées sur un modèle requête-réponse et ne sont donc pas
idéales pour la communication en temps réel.
3. Gestion des versions
Vous devez mettre en œuvre des changements à mesure que les API évoluent.
Cependant, la gestion de la compatibilité descendante et du contrôle de version peut
s'avérer difficile, en particulier lorsqu'il s'agit d'une large base d'utilisateurs et de
plusieurs versions de clients.
4. Manque de découvrabilité :
Découvrir les ressources disponibles et leurs capacités peut s'avérer difficile sans
une documentation appropriée. Les API REST s'appuient souvent sur une
documentation externe et il n'existe aucun moyen standard de découvrir les
ressources de manière dynamique.
5. Problèmes de sécurité :
Bien que vous puissiez sécuriser les API REST à l'aide de HTTPS et de mécanismes
d'authentification, la sécurité reste une préoccupation. Vous devez mettre en œuvre
une authentification, une autorisation et un cryptage appropriés pour garantir la
confidentialité et l'intégrité des données.
 Chapitre 2
Interagir avec une API REST via HTTP
Comme indiqué plus haut, les APIs REST utilisent un moyen pour acheminer les
requêtes, du client vers le serveur, et du serveur vers le client. Ce transfert se fait au
travers du protocole HTTP. Le serveur et le client peuvent être dans le même réseau,
dans ce cas ils sont connectés à travers un Intranet, ou dans des réseaux différents
et donc connectés au travers d’Internet
HTTP, abrégé de Hypertext Transfer Protocol (ou protocole de transfert hypertexte
en français) est un protocole de la couche application du modèle OSI servant à
transmettre des documents hypermédias, comme HTML. Il a été conçu pour la
communication entre les navigateurs web et les serveurs web mais peut également
être utilisé à d'autres fins. Il suit le modèle classique client-serveur : un client ouvre
une connexion, effectue une requête et attend jusqu'à recevoir une réponse. Il s'agit
aussi d'un protocole sans état, ce qui signifie que le serveur ne conserve aucune
donnée du client (on parle d'état) entre deux requêtes.
Le serveur ne conserve aucune donnée du client, indique que sans analyser les
informations fournies dans une requête et sans utiliser un registre tiers comme une base de
données, le serveur n’a aucun moyen d’identifier que deux requêtes proviennent d’un même
client.

A) Une requête HTTP

Une requête HTTP c’est l’ensemble des informations envoyées par les clients
(navigateurs Web, …) pour avoir accès aux ressources (pages Web en HTML,
fichiers CSS, JS, données JSON, XML, …) disponibles sur le serveur.
Chaque requête contient une série d’informations, encodées et divisées en sections :
• La version du protocole HTTP utilisé par le client (version 3, en utilisation
actuellement) : cette information permet au serveur de savoir comment
décoder les informations reçues.
• L’URL, chaîne de caractère permet d’identifier de manière unique une
ressource.
• Une méthode, ou un verbe : indique le type d’action à effectuer sur le
serveur.
• Les informations d’en-tête : ce sont des données stockées sous forme de
pair clé-valeur, qui fournisse des informations complémentaires sur la
requête. Il contienne également lorsque nécessaire des informations qui
permettent de garantir que la requête du client est authentique et qu’il peut
accéder à la ressource.
• Corps (facultatif) : fournit les informations nécessaires au traitement de la
requête.

Nous allons étudier en détail quelques sections d’une requête HTTP.

 a) La méthode HTTP

Une méthode HTTP, ou verbe HTTP, indique l'action que la demande HTTP attend
du serveur interrogé. Chaque verbe est associé à une action spécifique.
• GET : demande une représentation de la ressource spécifiée. Les
requêtes GET doivent uniquement être utilisées afin de récupérer des
données.
• HEAD : demande les en-têtes qui seraient retournés si une requête GET
était effectué. Il sert pour connaître la taille d’un fichier avant de lancer le
téléchargement, mais également pour vérifier qu’une ressource disponible
dans le cache est toujours valide ou non.
• POST : est utilisée pour envoyer une entité vers la ressource indiquée. Elle
sert à notifier d’une volonté de changement d'état c’est-à-dire la création
d’une nouvelle ressource, ou la modification d’une ressource existante sur
le serveur.
• PUT : envoie une demande de modification complète de la représentation
de la ressource visée, par le contenu du corps de la requête. Normalement
plusieurs requêtes PUT avec le même corps doivent produire le même
résultat ; puisque soit la représentation de la ressource est écrasée en
totalité par les données reçues, soit aucune modification n’est effectuée.
• DELETE : demande la suppression de la ressource identifiée par l’URL de
la requête.
• CONNECT : demande l’établissement d’un tunnel de communication
bidirectionnelle vers la ressource. Elle est utilisée pour établir des
connections sécurisées entre les clients et les serveurs ou sites web
utilisant SLL (HTPPS).
• OPTIONS : permet au client de demander et recevoir les options de
communication vers une ressource avec le serveur en globalité. Par
exemple, pour une ressource cette méthode permet d’obtenir la liste des
autres méthodes HTTP autorisées.
• TRACE : permet d’effectuer un test de parcours du chemin parcouru par
une requête du client, vers le serveur destinataire final.
• PATCH : demande une modification partielle de la ressource visée.
Contrairement à PUT, seules les informations à modifier sont contenus
dans le corps de la méthode ; il est donc plus léger.

b) Champs d’en-têtes
Cette section contient des informations textuelles stockées sous forme de paires clé-
valeur. Ils sont inclus dans chaque requête. Elles communiquent des informations
essentielles, comme le navigateur utilisé par le client et les données demandées.
 Champ d’en-tête Information communiquée Exemples
Format de contenu attendu par le text/html,
Accept
client application/json…
Accept-Language Langage attendu par le client
Contrôle la mise en cache de la
réponse, et indique la durée no-cache, max-
Cache-Control
maximale pendant laquelle une age=3600
réponse peut être mise en cache.
Indique la date et l'heure à laquelle Wed, 21 Oct 2015
Date
la requête a été envoyée [Link] GMT
User-Agent Indique les informations sur le client Chrome/58.0.3029.110
Tableau 2 - Quelques-unes des en-têtes de requêtes HTTP avec des exemples.

Figure 3 - Exemple de requête HTTP.

 c) Corps de la requête
C’est l’ensemble des informations que le client souhaite transmettre au serveur. Par
exemple lors d’une requête de connexion à son compte, le corps de la demande
contiendra un nom d'utilisateur et un mot de passe, ou toute autre donnée entrée
dans le formulaire. Le corps de la méthode peut être envoyé sous différents formats.
i) application/x-www-form-urlencoded : Les données sont
encodées sous la forme de paires clé-valeur séparées par le
symbole & (username=jdoe&password=secret).
ii) multipart/form-data : utilisé pour envoyer des données de
formulaire plus complexes, y compris des fichiers.

iii) application/json : les données sont encodées sous forme de

paires clé-valeur, avec des accolades {} entourant l'objet JSON

iv) text/xml : les données sont encodées sous forme de balises

XML, avec une balise racine entourant les données.

v) application/octet-stream : utilisé pour envoyer des données

binaires, sans aucun encodage spécifique.
Après transport de la requête, et son traitement une réponse est renvoyée vers le
client.
 B) Une Réponse HTTP
C’est l’ensemble des informations reçues par le client, suite à sa requête. Ces
informations sont également divisées en plusieurs sections :
• Un code de statut : il renseigne sur le statut soit du traitement effectué par
le serveur, soit de la ressource demandée.
• Les champs d’en-tête : ce sont des informations supplémentaires sur la
requête reçue et la réponse envoyée par le serveur.
• Le corps : c’est généralement la représentation dans un format donnée de
la ressource demandée par la requête ou une indication sur le statut du
traitement de la requête ou de la ressource.
Revoyons brièvement le rôle de chaque section :
a) Le code de statut
C’est un code à 3 chiffres dans l’intervalle de 100 fermé à 600 ouvert, qui donne une
indication sur soit :
• Le statut de la ressource ;
• La conformité de la requête ;
• Le statut de l’exécution des opérations de traitement de la requête par le
serveur.
Le premier chiffre indique le type ou la catégorie du statut et le reste des chiffres, la
nature exacte du statut.
Intervalle Nature de statut Description
[100 ; 200 [ Informatives Donne une information sur la ressource ou
le protocole. Généralement la ressource
n’est pas (encore) disponible ou elle n’est
pas pertinente ; le client doit alors patienter
et au cas échéant il est informé de l’URI qui
peut satisfaire sa demande.
[200 ; 300 [ Réussites Le serveur a exécuté la demande
reçue avec succès ; il a éventuellement
renvoyé la ressource attendue ou indiqué
au client que le traitement était en cours
(exemple : attente de validation par un
tierce).
[300 ; 400 [ Redirections Indique que soit plusieurs réponses sont
disponibles, soit la ressource n’est plus
temporairement ou définitivement
accessible via cette URL.
[400 ; 500 [ Erreurs Client Informe le client que soit l’URL, la méthode,
ou le corps de la requête ne permettent pas
de la traiter. Ils permettent d'indiquer
également si l’utilisateur n’as pas de droit
d’accès ou doit effectuer une action
préalable.
[500 ; 600 [ Erreurs Serveur Informe le client que le serveur a rencontré
une erreur dans le traitement de la requête,
et qu’il ne peut donc pas satisfaire la
demande.
Tableau 4 - Catégorie des codes de statuts des réponses HTTP.
Une expression est associée à chaque qui fournit plus d’informations sur la nature de
l’erreur.
Code Nature Description
Le serveur a reçu la requête initiale et attend la
100 Continue
suite.
Le serveur passe à un protocole différent à la
101 Switching Protocols
demande du client.
La requête a réussi et le serveur renvoie la
200 OK
réponse attendue.
La requête a été traitée avec succès et une
201 Created
nouvelle ressource a été créée
La requête a été acceptée mais n'a pas encore été
202 Accepted
traitée.
La requête a réussi mais le serveur ne renvoie pas
204 No Content
de contenu.
Il existe plusieurs choix pour la ressource
300 Multiple Choices
demandée.
La ressource demandée a été déplacée de
301 Moved Permanently
manière permanente vers une nouvelle URL.
La ressource demandée a été temporairement
302 Found
déplacée vers une nouvelle URL.
La ressource n'a pas été modifiée depuis la
304 Not Modified
dernière demande du client.
400 Bad Request La requête est invalide ou mal formulée.
Le client n'est pas autorisé à accéder à la
401 Unauthorized
ressource demandée.
Le client n'a pas les autorisations nécessaires pour
403 Forbidden
accéder à la ressource demandée.
La ressource demandée n'a pas été trouvée sur le
404 Not Found
serveur.
La méthode de requête n'est pas autorisée pour la
405 Method Not Allowed
ressource demandée.
Le serveur a rencontré une erreur interne lors du
500 Internal Server Error
traitement de la requête.
Le serveur agit en tant que passerelle et a reçu
502 Bad Gateway
une réponse invalide d'un serveur en amont.
Le service est temporairement indisponible en
503 Service Unavailable
raison d'une maintenance ou d'une surcharge.
Tableau 5 - Exemples de code de statuts HTPP les plus utilisés et leurs significations.

Pour compléter les informations fournies, et consulter tous les codes de statut
possibles, référer vous à cette ressource.
En dehors de ces codes standards et de cette plage, le serveur peut envoyer un autre
code correspondant à un statut. Cette information est alors généralement fournie dans la
documentation de l’API du service Web, pour permettre au client et à l’intégrateur de
comprendre la signification de ce code.
 b) Les champs d’en-tête
Ils sont du même type que ceux d’une requête et communiquent des compléments
d’informations sur la réponse.

Champ d’en-tête Information communiquée Exemples

Indique la longueur du contenu de
Content-Length 1234
la réponse en octets.
Indique le type du contenu de la text/html;
Content-Type
réponse (format MIME) charset=UTF-8
Contrôle la mise en cache de la
réponse, et indique la durée no-cache, max-
Cache-Control
maximale pendant laquelle une age=3600
réponse peut être mise en cache.
Indique la date et l'heure à laquelle Date: Wed, 22 Feb
Date
la réponse a été générée 2023 [Link] GMT
Indique la date et l'heure à partir
Expires: Wed, 22 Feb
Expires desquelles la réponse n'est plus
2023 [Link] GMT
considérée comme valide
Indique le nom et la version du Server: Apache/2.4.7
Server
serveur web (Ubuntu)
Tableau 6 - Champs d'en-tête les plus courants dans les réponses HTTP,

Figure 4 - Exemple de réponse http

 c) Le corps
Dans la majeure partie des cas, il correspond à une représentation de la ressource
demandée, dans un format de données particulier (JSON, XML, HTML, YAML, …).
Le format de transfert le plus répandu est le JSON car il a l’intérêt d’être léger et peut
être lu aussi bien par les humains que par les machines.
i) Texte brut (plain text) : il s'agit du format le plus simple, utilisé
pour envoyer du texte brut sans aucun formatage particulier.
ii) JSON (JavaScript Object Notation) : est utilisé pour envoyer des
données structurées au client.

iii) XML (eXtensible Markup Language) : permet également

d’envoyer des données structurées, avec une contrainte plus
stricte.

iv) YAML (Yet Another Markup Language ou YAML Ain't Markup

Language) : tend à simplifier et fusionner le format XML et
JSON.

v) octet-stream : utilisé pour envoyer des fichiers binaires au client

(images, PDF, vidéos, …).
D’autres formats de données peuvent être utilisés, notamment le CSV.
Pour en apprendre plus de manière exhaustive sur le HTTP, consulter cette
ressource.

Suivant le type et la nature des ressources, il peut nécessiter l’implémentation de

mécanismes qui permettent d’identifier le client émetteur d’une requête et de
s’assurer qu’il a les autorisations nécessaires pour accéder à la ressource visée par
sa requête.

C) Sécurité d’une API REST

Contrairement aux APIs SOAP, qui sont pensées pour interagir dans un système
contrôlé, les APIs REST sont généralement ouverts et accessibles au plus grand
nombre.
Deux mécanismes complémentaires permettent d’assurer la sécurisation des
ressources disponibles : l’authentification et l’autorisation.
• L’authentification (authentication) : permet d’associer une identité au client
émetteur de la requête. La requête contient l’identité du client et un moyen
qui permet au serveur de garantir que l’émetteur de la requête est bien qui
il prétend être. Lorsque l’identité n’a pas pu être vérifié, le serveur envoie
une réponse avec un code de statut 401.
• L’autorisation (authorization) : lorsque l’émetteur de la requête est identifié,
il faut ensuite déterminer si son identité lui donne le droit d’accéder à la
ressource demandée. Une comparaison est alors effectuée entre son
niveau d’accès et celui requis pour accéder à la ressource. Lorsque son
niveau d’accès est insuffisant pour accéder à la requête, le serveur envoie
une réponse avec un code de statut 403.

L’authentification est effectuée en analysant les informations envoyées par le client ;

l’autorisation est un processus interne au fonctionnement du serveur.

Explorons quelques manières courantes utilisées avec le protocole HTTP et les APIs
REST pour authentifier une requête.

a) Authentification de base (Basic Authentication) :

Dans cette méthode, le nom d’utilisateur et le mot de passe d’identité du client sont
encodés en base64 et envoyées dans l’entête de chaque requête émise.
Le fonctionnement est le suivant :
• Le client envoie une requête avec une information d’en tête formaté
comme suit : "Authorization: Basic [nom d'utilisateur:mot de passe encodé
en base64]".
• Le serveur décode l'en-tête d'autorisation et vérifie le nom d'utilisateur et le
mot de passe. S'ils sont valides, le serveur traite la requête et renvoie la
ressource demandée. Sinon, le serveur renvoie une réponse avec un code
d'état HTTP 401.
• Si l’information d’autorisation n’est pas présente dans l’entête de la
requête, en plus du code 401, le serveur renvoie dans l’entête de la
réponse : "WWW-Authenticate : Basic".
Bien qu’il soit facile à mettre en œuvre, il présente quelques failles de sécurité,
notamment l'interception de la requête avant sa réception par le serveur ; ainsi son
utilisation n’est conseillée que sur des connexions HTTPS sécurisées.
b) Authentification à base de clé d’API :
Dans cette méthode, une clé unique (appelée clé d'API) est fournie à chaque
utilisateur (client) ou application qui souhaite accéder à l'API :
• Le client qui souhaite accéder à une ressource de l’API, doit fournir dans
sa requête HTTP, sa clé d'API unique dans la requête.
• Le serveur vérifie la clé d'API et, s'il est valide, autorise l'accès à la
ressource demandée.
• Si la clé d'API est invalide ou manquante, le serveur envoie une réponse,
avec le code de statut 401.
Il n’y a pas d’exigence dans la section, ou le format de la clé d’API. Elle peut être
envoyée dans l'en-tête, dans la chaîne de requête de l'URL ou dans le corps de la
requête HTTP.
Cette méthode est simple à mettre en œuvre, et permettre au serveur de contrôler
l’accès aux ressources. En revanche la clé étant la seule manière d’identifier le client,
si une clé est volée ou compromise par un tiers, cela entraîne des accès non
autorisés aux ressources.
c) Authentification de porteur (Token-based Authentication) :
Cette méthode implique l’envoie dans chacune des requêtes du client, d’un jeton
d’authentification :
• Lors de la première connexion, le client envoie ses informations
d'identification (nom d'utilisateur et mot de passe) au serveur.
• Le serveur vérifie les informations d'identification et, si elles sont valides,
génère un jeton d'accès unique (Token) pour l'utilisateur.
• Le jeton d'accès est renvoyé au client ; ce dernier doit le stocker pour les
prochaines requêtes.
 • Lorsque le client souhaite accéder à une ressource protégée sur le
serveur, il envoie une requête HTTP avec le jeton d'accès dans l'en-tête
d'autorisation, formaté comme suit : "Authorization: Bearer [jeton d’accès]".
• Le serveur vérifie le jeton d'accès et, s'il est valide, autorise l'accès à la
ressource demandée, sinon envoie une réponse avec un code de statut
401.
L’intérêt premier de cette méthode est que le client ne fournit ces informations
d’identité qu’une seule fois. Ensuite le jeton peut avoir une durée de validité limitée et
révoquée à tout moment au niveau du serveur. En dernier pour limiter la charge de
travail du serveur principale, un serveur intermédiaire validant les jetons peut être
implémenter.
Cette méthode est utilisé dans d’autres méthodes d’authentifications comme, l’open
authorization (OAuth) ou l’authentification par les JSON Web Token.
OAuth (Open Authorization) est un protocole d'authentification et d'autorisation qui
permet à un utilisateur de donner à une application tierce un accès limité à ses ressources
sur un autre service, sans partager ses informations d'identification avec l'application.

d) JWT (JSON Web Token) :

C’est est une norme ouverte pour l'échange sécurisé d'informations entre plusieurs
parties. Voici comment elle fonctionne :
• Le client envoie une requête de connexion à un serveur, contenant ses
informations d'identification (par exemple, nom d'utilisateur et mot de
passe).
• Le serveur vérifie les informations d'identification du client et, s'il est
authentifié avec succès, crée un jeton JWT et le renvoie au client.
• Le jeton JWT contient des informations sur le client, telles que son
identifiant, son nom, ses rôles, etc. Le jeton est signé numériquement par
le serveur à l'aide d'une clé secrète.
• Le client stocke le jeton JWT et à chaque nouvelle requête visant une
ressource protégée, envoie le jeton JWT dans l'en-tête d'autorisation de la
requête HTTP.
• Le serveur vérifie la signature du jeton JWT à l'aide de la clé secrète et, s'il
est valide, extrait les informations sur l'utilisateur dans le jeton. Il autorise
ou refuse l'accès à la ressource en fonction des informations sur
l'utilisateur et des autorisations associées.

Ainsi s’achève notre tour d’horizon des différentes étapes d’interactions entre une un
client et un serveur, au travers d’une API REST, grâce au protocole de
communication HTTP.
 TP 1
Intégration d’une API
: Cas de l’API de PAYGATE GLOBALE

Objectif : utiliser l’outil POSTMAN pour intégrer et tester le fonctionnement complet

de l’API de paiement de Paygate Globale.

Contexte : Paygate Globale est un agrégateur de paiement mobile, qui permet au travers d’une API
simplifié d’interagir avec les différentes solutions de Mobile Money disponibles au Togo (Moov Money,
TMoney).
 Chapitre 3
Conception d’une API REST
La conception d’une API doit répondre à un besoin technologique et respecter un
cahier de charges.
Différences ressources et méthodologies existent, et peuvent être utiliser en amont
de l’implémentation purement technique pour obtenir le meilleur résultat.
 A) Cahier de charges

C’est un document, qui permet de décrire de manière exhaustive et ceci pour toutes
les personnes impliquées dans le processus de conception et développement, le
pourquoi, le comment de l’API.
Il décrit les fonctionnalités, les exigences et les contraintes d'une API. Il servira de
guide pour les développeurs qui vont concevoir et implémenter l'API.
Décrivons certaines sections clés qu’il peut contenir :
• Introduction : une brève description de l'API, de son objectif et de son
domaine d'application.
• Définitions : une liste des termes et des concepts clés utilisés dans le
document.
• Modèle de données : une description des données que l'API manipule, y
compris les schémas de données, les types de données, les relations entre
les données, etc.
• Exigences non fonctionnelles : une description des contraintes techniques, de
performance, de sécurité, de fiabilité, de scalabilité, auxquelles l'API doit
répondre.
• Exigences fonctionnelles : une description détaillée des fonctionnalités que
l'API doit fournir, une liste des ressources disponibles, et pour chacune d’elle,
les paramètres d'entrée et de sortie, les formats de données, etc.
• Spécification de l'API : une description détaillée des points de terminaison de
l'API, des méthodes HTTP utilisées, des codes de statut HTTP attendus, des
en-têtes HTTP requis, etc.
• Authentification et autorisation : une description des mécanismes
d'authentification et d'autorisation utilisés pour accéder à l'API, y compris les
rôles et les permissions.
• Tests : une description des tests à effectuer pour valider l'API, avec les
différents cas de test, les scénarios de test, les outils de test, etc.
• Maintenance et évolution : une description des procédures de maintenance et
d'évolution de l'API, y compris les mises à jour, les corrections de bugs, les
nouvelles versions, etc.

L’objectif recherché est de fournir suffisamment de détails pour permettre aux

développeurs de concevoir et d'implémenter l'API. Pour autant les concepteurs
doivent avoir la possibilité, d’effectuer des ajustements en cours de route.
 B) Documentation
C’est un ensemble de ressources qui décrivent les fonctionnalités et l'utilisation de
l'API. Elle est destinée aux développeurs souhaitant utiliser l'API pour intégrer des
fonctionnalités dans leurs applications.
Bien qu’elle puisse faire référence uniquement à la spécification technique principale
expliquant l’intégration des terminaisons de l’API, voici une liste exhaustive des
différentes sections que peut contenir la documentation d’une API :
• Introduction : une brève description de l'API, de son objectif et de son
domaine d'application.
• Authentification : une description des mécanismes d'authentification et
d'autorisation utilisés pour accéder à l'API, y compris les rôles et les
permissions.
• Spécification de l'API : une description détaillée des points de terminaison de
l'API, des méthodes HTTP utilisées, des codes de statut HTTP attendus, des
en-têtes et du corps HTTP requis, des réponses à attendre, et des différents
scénarios etc.
• Modèle de données : une description des données que l'API manipule, y
compris les schémas de données, les types de données, les relations entre
les données, etc.
• Exemples de requêtes et de réponses : des exemples de requêtes et de
réponses pour chaque point de terminaison de l'API, y compris les paramètres
d'entrée et de sortie, les formats de données, etc.
• Erreurs et codes d'erreur : une description des erreurs et des codes d'erreur
que l'API peut renvoyer, y compris les messages d'erreur et les solutions
possibles.
• SDK et bibliothèques client : une liste des SDK et des bibliothèques client
disponibles pour l'API, y compris les langages de programmation pris en
charge et les instructions d'installation.
• Tutoriels et exemples d'utilisation : des tutoriels et des exemples d'utilisation
de l'API pour aider les développeurs à comprendre comment utiliser l'API dans
des cas concrets.
• Support et assistance : une description des options de support et d'assistance
disponibles pour les développeurs qui utilisent l'API, y compris les forums de
discussion, les tickets de support, etc.
• Changements et mises à jour : une description des changements et des mises
à jour apportés à l'API, y compris les nouvelles fonctionnalités, les corrections
de bugs, les modifications de l'API, etc.
Une bonne documentation d’API doit être régulièrement mise à jour pour refléter les
changements et les mises à jour apportés à l'API.
 TP 2
Développement d’une API REST
 Chapitre 3
Aller plus loin
 A) Quelques recommandations
Voici quelques-unes des meilleures pratiques à adopter lors de la conception d'une
API REST :
1. Utiliser les bonnes méthodes HTTP : utiliser les méthodes HTTP appropriées
pour chaque opération CRUD (Create, Read, Update, Delete).
2. Utiliser une structure d'URL cohérente : utiliser une structure d'URL cohérente
et prévisible pour les ressources.
3. Utiliser les codes de statut HTTP appropriés : pour indiquer le résultat d'une
requête.
4. Utiliser la pagination : pour limiter le nombre de résultats renvoyés par une
requête. Cela permet d'améliorer les performances et de réduire la quantité de
données transférées.
5. Utiliser le versioning : pour gérer les changements apportés à l'API au fil du
temps. Cela permet de maintenir la rétrocompatibilité avec les versions
précédentes de l'API.
6. Utiliser des en-têtes HTTP appropriés : utiliser des en-têtes HTTP appropriés
pour transmettre des métadonnées supplémentaires avec les requêtes et les
réponses. Par exemple, utiliser Content-Type pour spécifier le format de la
charge utile et Authorization pour transmettre des informations
d'authentification.
7. Fournir une documentation claire et complète : fournir une documentation
claire et complète pour l'API, y compris les spécifications de l'API, les
exemples de requêtes et de réponses, et les guides de démarrage rapide.
8. Utiliser des codes d'erreur personnalisés : utiliser des codes d'erreur
personnalisés pour fournir des informations plus détaillées sur les erreurs
rencontrées lors de l'utilisation de l'API.
9. Utiliser la sécurité appropriée : utiliser la sécurité appropriée pour protéger
l'API contre les accès non autorisés et les attaques. Par exemple, utiliser
l'authentification et l'autorisation pour contrôler l'accès aux ressources, et
utiliser HTTPS pour chiffrer les données en transit.
10. Tester l'API : tester l'API pour s'assurer qu'elle fonctionne correctement et
qu'elle répond aux exigences de performance et de scalabilité.
 B) Comment optimiser la performance
La première règle est de ne pas tenter d’optimiser, lorsqu’il n’y a pas de problème de
performance. Mais lorsque des problèmes de performance surviennent, quelques
pratiques à adopter pour l’optimiser :
1. Utiliser la mise en cache : peut réduire le temps de réponse en stockant les
résultats des requêtes fréquemment utilisées. Il est important d'utiliser des en-
têtes HTTP appropriés pour indiquer la durée de vie de la mise en cache et de
mettre en œuvre une stratégie de mise en cache efficace.
2. Utiliser la compression : réduit la taille des données transférées entre le client
et le serveur, ce qui peut améliorer les temps de réponse.
3. Réduire la taille des ressources : écourte le temps de transfert et améliorer les
temps de réponse.
4. Utiliser la pagination : diminue la quantité de données transférées en une
seule fois.
5. Réduire le nombre de requêtes : (supprimer les requêtes intermédiaires)
regrouper les données connexes dans une seule ressource pour réduire le
nombre de requêtes nécessaires pour récupérer toutes les données.
6. Utiliser des index de base de données et optimiser les requêtes SQL :
l'utilisation d'index peut améliorer les temps de réponse en accélérant les
recherches dans la base de données. Également dans l’écriture des requêtes
SQL, prioriser l’efficacité et d'éviter les jointures inutiles.
 CONCLUSION
Ce cours a exploré les bases des différentes notions autour du développement, de la
conception, de la documentation et du test des APIs REST.

Les différentes notions théoriques abordés, sont les béaba utiles au quotidien aux
développeurs qui conçoivent ou consomment les API REST. En complément de ces
notions, plusieurs autres réflexes et concepts pratiques doivent être acquises pour
compléter la connaissance et la compréhension du développeur.

Les documentations fournies en début de document, permettront de compléter et de

détailler un peu plus toutes les notions évoquées.