Présentation d'une

API REST
 Table des
matières

Objectifs

I - Présentation d'une API

1. Notions de API et API REST

2. Comment fonctionne une API ?

3. Les différents types d'API

4. Architectures SOA et de microservices

5. Exemples d'API

II - Exercice : Activité d'auto-évaluation 1

III - Présentation d'une API REST

1. Les principes d'une API Rest

2. Quelques notions techniques de base d'une API Rest

3. LES VERBES ou METHODES HTTP

4. LES CODES RETOUR HTTP D'API REST

5. LE MODELE DE MATURITE DE RICHARDSON

6. Les formats de données d'une API Rest

7. SÉCURITÉ

8. VERSIONING

9. DOCUMENTATION

10. API MANAGEMENT

IV - Exercice : Activité d'auto-évaluation 2

Objectifs

A la fin de cette leçon, vous serez capable de :

Définir et présenter une API
Définir et présenter une API REST
 Présentation d'une API
Présentation d'une API

Présentation d'une API

I
Notions de API et API REST
Notions de API et API REST

1. Notions de API et API REST

Définition : Définition d'une API
Une API « Application Programming Interface » est un ensemble de définitions et de protocoles qui facilite la
création et l'intégration de logiciels d'applications.
- Elle est parfois considérée comme un contrat entre un fournisseur d'informations et un utilisateur
d'informations, qui permet de définir le contenu demandé au consommateur (l'appel) et le contenu
demandé au producteur (la réponse).
- Les API permettent à votre produit ou service de communiquer avec d'autres produits et services sans
connaître les détails de leur mise en œuvre. Elles simplifient le développement d'applications

Illustration :
- Par exemple, l'API conçue pour un service de météo peut demander à l'utilisateur de fournir un code
postal et au producteur de renvoyer une réponse en deux parties : la première concernant la température
maximale et la seconde la température minimale.
- En d'autres termes, lorsque vous souhaitez interagir avec un ordinateur ou un système pour récupérer des
informations ou exécuter une fonction, une API permet d'indiquer au système ce que vous attendez de lui,
afin qu'il puisse comprendre votre demande et y répondre.
Vous pouvez vous représenter une API comme un médiateur entre les utilisateurs ou clients et les
- ressources ou services web auxquels ils souhaitent accéder. Pour une entreprise, c'est aussi une solution
pour partager des ressources et des informations, tout en maintenant un certain niveau de sécurité, de
contrôle et d'authentification, en déterminant qui est autorisé à accéder à quoi.

Définition : Définition d'une API Rest

Une API REST (également appelée API RESTful) est une interface de programmation d'application (API ou
API web) qui respecte les contraintes du style d'architecture REST et permet d'interagir avec les services web
RESTful. L'architecture REST (REpresentational State Transfer) a été créée par l'informaticien Roy Fielding.

Les approches d'accès aux API

Il existe trois approches d'accès aux API :

- API privées : L'API n'est utilisable qu'en interne. Cette approche permet de garder un contrôle total sur
l'API.
 - API partenaires  : L'API est partagée avec certains partenaires de l'entreprise. Cette approche peut
générer de nouveaux flux de revenus sans compromettre la sécurité.
- API publiques  : L'API est accessible à tous. Cette approche autorise les tiers à développer des
applications qui interagissent avec votre API et peut devenir source d'innovations.

Utilité des API

- Les API sont de plus en plus utilisées dans le milieu professionnel car elles répondent à plusieurs besoins.
Elles permettent la création flexible d'application et de moderniser les structures des sites web et
applications métier.
- Une API offre la possibilité aux entreprises d'ouvrir leurs données à leurs clients, fournisseurs et
partenaires de manière sécurisée. Tout est interconnectable plus facilement, ce qui représente un gain de
temps et d'efficacité pour les équipes de développeurs.
- Les API permettent d'étendre le SI des entreprises grâce à l'interopérabilité des systèmes. Les échanges de
données entre les différentes applications sont possibles dans toutes circonstances.
Comment fonctionne une API ?
Comment fonctionne une API ?

2. Comment fonctionne une API ?

- Pour développer une API, il faut un serveur et un client.
- Le serveur fournit et exécute le programme de l'API. Il attend qu'on lui envoi une requête pour lui
demander des données.
- Le client est un programme distinct qui demande et reçoit les données transmises par l'API. Ce client peut
être un site web, une application, une machine, un logiciel métier, un smartphone, etc...
- Il faut considérer l'API comme une interface d'échange de données entre plusieurs systèmes. Le client
envoie une requête de données au serveur. Le serveur va extraire et collecter des données issues de sources
disparates comme les applications, web services, bases de données etc...
- Il va ensuite standardiser le format de ces différentes données pour les rendre compatibles avec le client.
L'API crée un langage universel pour faire communiquer le client et le serveur.
- On parle d'intégration ou de systèmes intégrés lorsque plusieurs systèmes sont reliés par une API. Ce type
de système est interopérable et permet aux différentes applications d'échanger entre elles.
Les différents types d'API
Les différents types d'API

3. Les différents types d'API

- SOAP : le « Simple Object Access Protocol », ou SOAP. Les API conçues d'après le protocole SOAP
utilisent le format XML pour leurs messages et reçoivent des requêtes via HTTP ou SMTP.
- XML-RPC : Remote Procedure Call (RPC) est le protocole le plus ancien et le plus simple utilise dans
les API. Ce type de protocole etait initialement destine au client pour creer des codes sur un serveur.
Cependant, XML-RPC utilise le langage XML (Extensible Market Language) pour encoder les
commandes.
- JSON-RPC : Tres similaire a la methode XML, JSON- RPC utilise le format JSON (Javascript Object
Notation) pour transferer des donnees. Avec l'une ou l'autre methode RPC, les exigences strictes de
formatage des donnees rendent tres difficile pour les developpeurs d'effectuer des mises a jour.
- REST : Le « Representational State Transfer », ou REST, est une autre tentative de normalisation. Les
API Web qui respectent les contraintes de l'architecture REST sont appelées API RESTful. Ces deux
éléments diffèrent sur un point fondamental : SOAP est un protocole, alors que REST est un style
d'architecture. Cela signifie qu'il n'existe aucune norme officielle qui régit les API Web RESTful. Selon la
définition proposée par Roy Fielding dans sa thèse « Architectural Styles and the Design of Network-
based Software Architectures », les API sont RESTful tant qu'elles respectent les six contraintes de
conception d'un système RESTful que nous verrons à la suite.
 - APIs natives ou de navigateur : il s'agit des APIs des systèmes d'exploitation (par exemple :
accéléromètre ou système de fichiers sur smartphone etc.) ou des navigateurs (par exemple : audio ou
géolocalisation en HTML5, XMLHttpRequest etc.) et qui sont accessibles à travers les applications web et
mobiles.
- APIs Push ou Streaming : ce sont les APIs qui ouvrent un flux continu d'échange de données entre client
et serveur, telles que les websockets ou webhooks.
- GraphQL : dernière tendance des architectures d'APIs, c'est également un langage de requête permettant
d'obtenir des données complexes de sources différentes en une seule requête.
Architectures SOA et de microservices
Architectures SOA et de microservices

4. Architectures SOA et de microservices

- Les deux approches architecturales qui utilisent le plus les API distantes sont l'architecture orientée
services (SOA) et l'architecture de microservices. La SOA est l'approche la plus ancienne. Elle visait à
l'origine à améliorer les applications monolithiques. Par définition, une application monolithique fait
tout.
- Les architectures de microservices fonctionnent d'une manière très similaire, dans le sens où elles utilisent
des services faiblement couplés. Par contre, elles poussent la déstructuration de l'architecture classique
encore plus loin. Les services qui composent l'architecture de microservices utilisent une structure de
messagerie commune, telle que les API RESTful. Ils se servent des API RESTful pour communiquer
entre eux simplement, sans convertir leurs données ni recourir à des couches d'intégration
supplémentaires.
Exemples d'API
Exemples d'API

5. Exemples d'API
Les APIs et les SDK pour Google Maps

- Google Maps est un exemple très connu d'intégration d'API. C'est un célèbre service de cartes de
navigation en ligne.
- Sur la plate-forme Google Maps, les développeurs peuvent accéder à des SDK et à des API qu'ils pourront
intégrer dans leurs propres applications, programmes et sites internet de façon rapide et simple.
- Grâce à l'API Maps JavaScript, les propriétaires de sites internet peuvent par exemple ajouter des cartes
interactives en toute simplicité.
- Cette possibilité est particulièrement intéressante pour les boutiques et les restaurants dont le succès
commercial dépend souvent de la capacité de leurs clients à trouver leurs locaux.

API tierces courantes

Nous avons plusieurs autres API publiques telles que :

- l'API Graph de Facebook permet aux applications d'interagir avec l'application Facebook, notamment
pour publier des messages, de gérer des annonces, de collecter des données, de gérer des paiement.
- L'API Twitter vous permet d'afficher vos derniers tweets sur un site web.
- Les API Telegram permettent d'intégrer le contenu de canaux Telegram sur un site web et de prendre en
charge les bots.
- L'API YouTube vous permet d'intégrer des vidéos YouTube sur votre site, de faire des recherches sur
YouTube, de construire des listes de lecture, etc.
- L'API Pinterest fournit des outils pour gérer des tableaux et épingles Pinterest et de les inclures à votre site
web.
- etc.
 Exercice : Activité d'auto-évaluation 1
Exercice : Activité d'auto-évaluation 1

Exercice : Activité d'auto-

évaluation 1 II

Exercice : Signification de API

Une API signifie :

 Application Programme Interface

 Application Programming Interfacing

 Application Programming Interface

 Apply Programme Interface

 Application Programming Interaction

Exercice : Les différents types d'API
Différents types d'API sont :

 GraphQL

 SOAP

 GraphXL

 SIGNAL

 RESTE

 REST
 Présentation d'une API REST
Présentation d'une API REST

Présentation d'une API

REST III

- REST est un ensemble de contraintes architecturales. Il ne s'agit ni d'un protocole, ni d'une norme.
Les développeurs d'API peuvent mettre en œuvre REST de nombreuses manières.
- Lorsqu'un client émet une requête par le biais d'une API RESTful, celle-ci transfère une représentation
de l'état de la ressource au demandeur ou point de terminaison.
- Cette information, ou représentation, est fournie via le protocole HTTP dans l'un des formats suivants :
JSON (JavaScript Object Notation), XML, etc.
- Le format de données le plus utilisé est JSON, car, contrairement à ce que son nom indique, il ne dépend
pas d'un langage et peut être lu aussi bien par les humains que par les machines.

Les principes d'une API Rest

Les principes d'une API Rest

1. Les principes d'une API Rest

LES 6 CONTRAINTES DE «ROY FIELDING»

Une API RESTful doit remplir les critères suivants :

- Une architecture client-serveur : une architecture REST est composée de clients, de serveurs et de
ressources et elle traite les requêtes via le protocole HTTP.
- Un serveur sans état : le contenu du client n'est jamais stocké sur le serveur entre les requêtes. Les
informations sur l'état de la session sont, quant à elles, stockées sur le client.
- Une mémoire cache : la mise en mémoire cache permet de se passer de certaines interactions entre le
client et le serveur.
- Un système à couches : des couches supplémentaires peuvent assurer la médiation dans les interactions
entre le client et le serveur. Ces couches peuvent remplir des fonctions supplémentaires, telles que
l'équilibrage de charge, le partage des caches ou la sécurité.
- Code à la demande (facultatif) : un serveur peut étendre les fonctionnalités d'un client en lui transférant
du code exécutable.
- Interface uniforme : cette contrainte est capitale pour la conception des API RESTful et couvre quatre
aspects différents :
 - Identification des ressources dans les requêtes : les ressources sont identifiées dans les requêtes
et sont séparées des représentations retournées au client.
- Manipulation des ressources par des représentations : les clients reçoivent des fichiers qui
représentent les ressources. Ces représentations doivent contenir suffisamment d'informations pour
être modifiées ou supprimées.
- Messages autodescriptifs : tous les messages renvoyés au client contiennent assez d'informations
pour décrire la manière dont celui-ci doit traiter les informations.
- Hypermédia comme moteur du changement des états applicatifs : après avoir accédé à une
ressource, le client REST doit être en mesure de découvrir toutes les autres actions disponibles par
des hyperliens.
Ces contraintes peuvent sembler difficiles à appliquer, mais dans les faits, elles le sont moins qu'un protocole. C'est
pour cette raison que les API RESTful sont en train de prendre le pas sur les API SOAP.
Ces dernières années, la spécification OpenAPI s'est imposée comme la norme commune pour définir les API
REST. La norme OpenAPI permet aux développeurs de créer des interfaces d'API REST de manière à ce que les
utilisateurs puissent les comprendre avec un minimum d'approximation.
Quelques notions techniques de base d'une API Rest
Quelques notions techniques de base d'une API Rest

2. Quelques notions techniques de base d'une API Rest

Les ressources et collections

Les données REST sont représentées dans ce qu'on appelle des ressources.
Une ressource ou ressource web peut être tout type d'objet nominal (on lui attribue un nom) que vous pouvez
utiliser pour représenter les données dans votre application.
Les ressources sont regroupées dans un groupe que l'on appelle une collection. On s'y réfère avec la forme au
pluriel du nom de la ressource.

Ressources publiques ou privées

Toutes les ressources exposées par votre API ne nécessitent pas le même niveau de vigilance. On distingue deux
types de ressources.
- Ressources publiques
Comme leur nom l'indique, les informations contenues dans ces ressources sont publiques. Par exemple,
/products ou /offers sont des ressources qui sont probablement faciles à consulter sur votre site Internet,
sans aucune connexion préalable de l'utilisateur.
Même si les données exposées sont publiques, il est conseillé d'utiliser une passerelle d'API (les passerelles
d'API régissent le trafic des API) ou de mettre en place une stratégie d'API-KEY. Cela vous permettra de
gérer les quotas d'utilisation des ressources et donc d'éviter des abus, et analyser l'utilisation des API.
- Ressources privées
Il s'agit de ressources auxquelles tout le monde ne doit pas avoir accès, en général des informations qui
sont propres à un utilisateur : un historique de commandes, des informations bancaires, des données
personnelles, etc. De telles informations ne doivent être accessibles que par leur propriétaire.

Les URI et Endpoints

- REST est une architecture orientée ressources où chaque ressource est accessible via un identifiant unique
(URI).
- Le path (ou chemin) que vous donnez à votre API lui permet de savoir exactement où se trouvent les
données que vous voulez récupérer.
- Si une ressource est l'objet qui stocke vos données, pour les récupérer vous allez avoir besoin d'un
identifiant de ressource uniforme, ou URI pour Uniform Resource Identifier. L'URI est le moyen
d'identifier votre ressource, comme une étiquette.
- Un endpoint est une URL/URI qui fait partie d'une API. Si un URI est comme un chemin de fichier, alors
un endpoint est comme l'adresse complète du fichier.
 - L'URL de la requête est l'endpoint complet que vous utilisez pour votre requête. Il associe le nom de
domaine + le path de votre ressource.
- Un endpoint est de la forme : http://api.example.com/collection/

HATEOAS

Par définition, HATEOAS (Hypermedia As The Engine Of Application State) est une contrainte sur la présence
de liens au niveau des ressources pour permettre une navigation exploratoire.
Malgré l'omniprésence de cette contrainte dans le Web (liens hypertexte), elle est rarement intégrée dans les APIs
REST car beaucoup considèrent qu'une bonne documentation est suffisante pour mieux explorer une API.
D'ailleurs, plusieurs grands noms d'Internet dont Facebook, Twitter et Amazon n'ont pas pris en considération ce
niveau 3.
Toutefois, HATEOAS est devenu un terme définissant une API complètement mature.
Ci-dessous un exemple d'une réponse en JSON valide HATEOAS avec les liens self et list.

1{
2 "id": 1,
3 "immat": "aa111aa",
4 "marque": "peugeot",
5 "links": [
6 {
7 "rel": "self",
8 "href": "https://api.site.fr/vehicules/1"
9 },
10 {
11 "rel": "list",
12 "href": "https://api.site.fr/vehicules"
13 }
14 ]
15 }

Comme vous pouvez le constater, les liens sont au niveau de l'attribut links. Pour l'instant, il n'y a aucune règle de
nomenclature sur les attributs. En revanche, il existe des efforts pour standardiser les principes HATEOAS.
JSON-LD et Hydra sont en tête de course pour être adoptés par le W3C.
LES VERBES ou METHODES HTTP
LES VERBES ou METHODES HTTP

3. LES VERBES ou METHODES HTTP

REST a su profiter des verbes HTTP pour définir des spécifications d'échange facilement intégrables à tout
système.
Le CRUD est la liste des actions de bases que vous pouvez effectuer sur une ressource. C'est un acronyme qui
signifie Create (créer), Read (lire), Update (mettre à jour), et Delete (supprimer). Bien que le CRUD ne constitue
pas vraiment un mécanisme technique en soi, chaque action CRUD est associée à un verbe HTTP  ; Create
(POST), Read (GET), Update (PUT), Delete (DELETE). Les méthodes HTTP :
- GET : Permet de récupérer les données d'une ou plusieurs entités dans une ressource. Il est possible de
filtrer par des paramètres dans l'url.
Ex : GET https://api.site.fr/vehicule?immat=aa111aa
- POST  : Permet de rajouter des entités à une ressource. Les données sont envoyées dans le corps de la
requête.
Ex : POST http://api.monApp.com/utilisateurs/{« username »: »ti-nouveau », « location »: »Toronto »}
- PUT : Permet de modifier les données d'une entité dans une ressource.
L'url doit indiquer l'identifiant de l'entité. Si l'identifiant est inexistant, l'entité devrait être créée.
Ex : curl -H -X PUT -d '{"immat":"aa111aa", "marque": "peugeot"}' https://api.site.fr/vehicules/1
- PATCH (OPTIONNEL) : Permet de modifier en partie les données d'une entité dans une ressource.
Ce verbe ne fait pas partie des opérations de base pour la persistance des données (CRUD) mais pourrait
être considéré comme une extension au verbe PUT lui permettant de simplifier les mises à jour partielles.
 - DELETE : Permet de supprimer une entité dans une ressource.
Voir aussi : https://fr.wikipedia.org/wiki/Representational_state_transfer

Par exemple une API REST qui gère des articles d'un blog pourrait mettre à disposition les actions suivantes :

Action Méthode URI

Récupérer la liste des articles GET /api/posts

Récupérer un article en GET /api/posts/8

particulier

Récupérer le détail d'un article GET /api/posts/8/details

Ajouter un article POST /api/posts

Modifier un article en particulier PUT /api/posts/8

Supprimer un article en DELETE /api/posts/8

particulier

LES CODES RETOUR HTTP D'API REST

LES CODES RETOUR HTTP D'API REST

4. LES CODES RETOUR HTTP D'API REST

Les codes retours permettent de donner un statut aux réponses renvoyées par l'API.

LE MODELE DE MATURITE DE RICHARDSON

LE MODELE DE MATURITE DE RICHARDSON

5. LE MODELE DE MATURITE DE RICHARDSON

Le modèle de maturité de Richardson définit 4 niveaux de développement dans les APIs REST (de 0 à 3) dont le
niveau 3 représente une API totalement RESTful.
La différenciation entre les 4 niveaux peut se baser sur 4 critères:

Les formats de données d'une API Rest

Les formats de données d'une API Rest

6. Les formats de données d'une API Rest

Une doit transmettre les données dans un format que l'autre comprendra. Les formats les plus couramment utilisés
par les API modernes sont JSON (JavaScript Object Notation) et XML (Extensible Markup Language).

JSON

Beaucoup d'API récentes ont adopté JSON comme format car il est construit à partir du langage de
programmation JavaScript, que l'on trouve employé partout maintenant sur le web et qui est utilisable à la fois en
front-end et en back-end. JSON est un format extrêmement simple qui comporte deux parties : les clés (keys) et
les valeurs (values). Les clés représentent un attribut de l'objet que l'on décrit.
Voyons à quoi ressemblerait notre commande en JSON :

1{
2 "pâte": "originale",
3 "garniture": ["fromage", "pepperoni", "ail"],
4 "statut": "en cours de cuisson",
5 "client": {
6 "nom": "Brian",
7 "téléphone": "573-111-1111"
8 }
9}

Dans l'exemple JSON ci-dessus, les clés sont les mots à gauche, ils décrivent les attributs de notre commande de
pizza. Les valeurs sont à droite, ce sont les détails de notre commande.

XML

XML existe depuis 1996 et avec l'âge il s'est transformé en un format de données mature et puissant. Tout comme
JSON, XML fournit des blocs nous permettant de structurer les données. Le bloc principal est appelé un nœud
(node).
Voyons ce que donnerait notre commande en XML :

1 <commande>
2 <pâte>original</pâte>
3 <garnitures>
4 <garniture>fromage</garniture>
5 <garniture>pepperoni</garniture>
6 <garniture>ail</garniture>
7 <garnitures>
8 <statut>en cours de cuisson</statut>
9 </commande><commande>
10 <pâte>original</pâte>
11 <garnitures>
12 <garniture>fromage</garniture>
13 <garniture>pepperoni</garniture>
14 <garniture>ail</garniture>
15 <garnitures>
16 <statut>en cours de cuisson</statut>
17 </commande>

XML commence toujours avec un noeud racine (root node), qui dans notre exemple est "commande". À
l'intérieur, on trouve des noeuds "enfants". Le nom de chacun nous renseigne sur l'attribut de la commande
(comme les clés en JSON) et les données à l'intérieur sont les détails (comme les valeurs en JSON)
 SÉCURITÉ
SÉCURITÉ

7. SÉCURITÉ
D'une manière générale, une API est censée être sécurisée et protégée contre les requêtes anonymes.

En pratique, trois techniques sont principalement utilisées pour sécuriser une API:
- HTTP Basic Authentication
- Oauth
- OpenID
>> HTTP Basic Authentication
Il s'agit de la solution la plus simple. Consiste à envoyer le login et le mot de passe dans l'entête de chaque
requête.
Bien évidemment, il est fortement conseillé d'utiliser le protocole HTTP en mode chiffré (HTTPS) pour ne pas
circuler le mot de passe en claire dans les trames réseaux (faille aux attaques de type MITM).
Pour plus de sécurité, surtout si le client de l'API est à l'extérieur de votre réseau, il est préconisé d'utiliser un
jeton de sécurité JWT (Json Web Token). Le JWT devrait avoir une durée de vie (TTL) limitée.
>> Oauth
Oauth est un protocole de délégation d'autorisation nécessitant un serveur tiers comme fournisseur d'accès.
Malgré la complexité de sa mise en place, ce protocole est très apprécié pour sa sécurité.
Il existe deux versions:
Oauth 1.0 – Il s'agit de la version la plus dure à mettre en place car nécessite un partage de clé entre client et
serveur pour le calcul d'une signature (même principe que SSL). Cette version est recommandée pour les APIs
sans HTTPS.
Oauth 2.0 – Cette version est plus aisée à mettre en place car ne dispose pas de calcul de signature. Par contre, en
l'occurrence le HTTPS est exigé. Néanmoins, cette version est moins sécurisée que Oauth 1.0.
>> OpenID
De base, OpendID est un système d'identification en mode SSO. Il permet à un client de se connecter auprès de
plusieurs sites sans devoir créer un compte à chaque fois.
Le mode de fonctionnement ressemble à celui de Oauth. Il faut un fournisseur d'identité (OpendID providers)
pour établir un lien de confiance entre le client et le serveur. Souvent, le fournisseur d'identité est un grand nom du
Web (facebook, twitter, google, ...).
D'autre part, cette solution ne permet pas de gérer l'authentification. De ce fait, il existe une deuxième version
(OpenID Connect) qui intègre une sous couche Oauth.
VERSIONING
VERSIONING

8. VERSIONING
Comme toute chose dans la vie, une API est amenée à bouger dans le temps.
 Les modifications au niveau des ressources sont souvent problématiques car nécessitent des mises à jour côté
client qui peuvent s'avérer très compliqués, surtout si ce dernier est en dehors du périmètre (partenaire ou
application mobile). De ce fait, il est préconisé de ne pas modifier les services mais plutôt d'en créer de nouveaux.
En général, il y a trois façons de versioning:
- Via l'URL – Consiste à rajouter le numéro de version dans l'URL de chaque ressource.
- Via l'entête HTTP – S'appuie sur des mécanismes d'identification de version depuis l'entête de la requête
(AcceptHeaderVersioning).
- Via les paramètres – Dans ce type de gestion, la version est passée dans les paramètres de la requête.
Même si cela peut paraître confus avec l'une des contraintes du REST (Uniform interface), le versioning via
l'URL est la solution la plus adoptée dans les APIs.
DOCUMENTATION
DOCUMENTATION

9. DOCUMENTATION
La documentation est un élément central pour faire en sorte que les personnes puissent exploiter une API. Il est
important que cette documentation soit rédigée par les développeurs eux-même.
Voici deux solutions pour la mise en oeuvre d'une documentation efficace:
- CARTE – Solution basée sur Jekyll.
- http://apidocjs.com/ – Solution en Javascript (Node.js).
API MANAGEMENT
API MANAGEMENT

10. API MANAGEMENT

Comme nous venons de le voir, une API demande beaucoup d'affection (sécurité, versioning, documentation). De
plus, de nouveaux besoins ont apparu, comme: le contrôle d'accès par quotas la monétisation de l'utilisation le
cache et la scalabilité sur le Cloud.
C'est ainsi que des solutions d'API Management (ou API Gateway) ont commencé à voir le jour afin de répondre
à ces besoins. Dans ces solutions, voici quelques unes que je trouve intéressantes:
- Kong– Solution open-source basée sur un système de plugins.
- Ty – Solution open-source facilement intégrable et disponible en version dockerisée.
- https://gravitee.io/ – Solution open-source en Java.
- Zuul – Solution open-source en Java.
- API Umbrella – Solution open-source en Java.
 Exercice : Activité d'auto-évaluation 2
Exercice : Activité d'auto-évaluation 2

Exercice : Activité d'auto-

évaluation 2 IV

Exercice : Signification de REST

REST signifie :

 Representational State Transfer

 Representational Element State Transfer

 Represention Element State Transfer

 Real Element State Transfert

Exercice : Notion de REST
REST est :

 un protocole web

 un ensemble de contraintes architecturales

 un design pattern

 une norme de W3C

Exercice
REST est :

 basé sur le protocole HTTP

 basé sur le postulat de ROY FIELDING

 un ensemble de protocoles

 basé sur les web services

 basé sur le protocole RPC