Le document aborde la conception d'APIs avec une focus sur l'architecture REST et ses principes fondamentaux, mettant en évidence l'importance de la décomposition des problèmes en tâches plus simples. Il décrit également l'évolution des APIs, les différences entre diverses architectures, ainsi que les caractéristiques qui rendent les APIs REST faciles à comprendre pour les développeurs. Enfin, le texte présente un modèle de maturité proposé par Richardson pour classer les APIs en fonction de leur conformité aux principes REST.

1. LE DESIGN D'API
AVEC MULESOFT
04 Nov 2020

2. POURQUOI CONCEVOIR UNE
API ?

3. « Voici la philosophie d'Unix :
Écrivez des programmes qui effectuent une seule chose et qui le font
bien.
Écrivez des programmes qui collaborent.
Écrivez des programmes pour gérer des flux de texte, car c'est une
interface universelle. »
(Douglas McIlroy, ~1970)

4. Les APIs permettent de décomposer de gros
problèmes en petits problèmes
Avec une API, un programme délègue une
tâche à un autre programme :
Au sein de la même application
Dans un processus ou système tiers
Intérêts
Simplification des programmes
Gain de temps
Ouverture aux autres développeurs
Documentation
Sécurisation possible
POURQUOI

5. 02
COMMENT SONT CONÇUES LES APIS

6. 1990 : Network-based Vs Distributed
Calcul sur des dispositifs physiques distincts : Unix DCE/RPC
(Distributed Computing Environment / Remote Procedure Call)
Sur un seul périphérique (Windows OS) : Microsoft COM/OLE
(Common Object Model/Object Linking and Embedding)
Normalisation des protocoles
Neutralité vis-à-vis de la plateforme et du langage
De bibliothèques logicielles qui masquent les détails de la
couche transport
Un document IDL (Interface Definition Language) qui fait office
de contrat de service.
Exemples :
CORBA (Common Object Request Broker Architecture)
Java RMI (Remote Method Invocation)
DCOM (Distributed COM) de Microsoft
Fin des années 90 : XML-RPC
Deux caractéristiques-clés pour la neutralité et la fiabilité :
Les payloads sont au format texte
Le transport utilise HTTP plutôt qu'un système propriétaire
Standardisation avec WS-*
Architecture SOA
LA RECHERCHE DU GRAAL

7. WORSE IS BETTER
2000 : First web APIs
Salesforce
2000 : the REST Architecture Principles defined by Roy Fielding
https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
Ebay
EURÊKA

8. ROA – « Ressource Oriented Architecture » :
Qualifie l’architecture d’un système
informatique respectant les contraintes du
style architectural REST.
Le World Wide Web en est un parfait exemple :
les pages, images, fichiers que les sites
exposent en sont les ressources ; le navigateur
est le client.
ROA est SOA
Format d'échange texte
Protocole ouvert et résilient
REST ARCHITECTURE
ROA SOA

9. REST – « Representational State Transfert » :
Style d’architecture, c’est-à-dire un ensemble
de contraintes appliquées lors de la conception
(ex. client-serveur, sans état…) d’un système
permettant de lui assurer certaines qualités (ex
: scalabilité, réutilisabilité, fiabilité…) au
détriment de certains aspects (ex : latence…)
N’est pas la solution universelle
REST ARCHITECTURE

10. Un service REST expose des ressources =
noms. Leurs URI permettent à des
applications tierces de les utiliser
D’un point de vue sémantique, une ressource
porte une partie du modèle métier du
service, un de ses concepts. Par exemple une
ressource « produitDisponible » peut à
un moment correspondre à « produit1 »
puis plus tard à « produit2 »
Les ressources sont accédées de manière
uniforme via un jeu d’opérations limité de
type CRUD = verbes (HTTP : POST, GET,
UPDATE, DELETE…)
Lors d’un échange client-serveur, c’est une
des représentations de la ressource qui est
transférée.
REST EN PRATIQUE

11. Pile protocolaire légère, souvent un client
HTTP et une librairie JSON ou XML suffisent
Lisibilité du format JSON par un développeur
et support natif par les navigateurs, tablettes
et smartphones
Hormis les fonctions de recherche et certains
paramètres de requêtes spécifiques, toutes les
API REST partagent des caractéristiques
communes qui les rendent facilement
compréhensible par un développeur. Les
ressources offertes lui sont le plus souvent
nouvelles, mais il sait déjà comment les
manipuler (CRUD)
Les pré-requis en terme d’outillage et de
connaissance de standard sont faibles
SUCCÈS DES WEBSERVICES REST
Simplifie les problématiques
d’interopérabilité
Simplicité apparente, en général
le développeur doit connaître la
représentation des ressources
pour savoir comment interagir
avec le service. D’un service à un
autre il n’y a pas de capitalisation.
Il n’est pas nécessaire de lire
d’indigestes spécifications et de
mettre en place des usines
logicielles

12. A force de qualifier de « REST » toute API
différente de SOAP, le sens premier a été
galvaudé.
Partant de ce constat Richardson propose
de les classer en 4 catégories, des plus
éloignées au plus proches du style
architectural présenté par Fielding :
Niveau 0 : RPC sur HTTP et utilisation de POX
(Plain Old XML). Toutes les requêtes sont
adressées à la même URL et l’utilisation des
codes retour HTTP est fantaisiste
Niveau 1 : Utilisation de plusieurs ressources
Niveau 2 : Utilisation des verbes et codes
retour HTTP permettant d’exposer une
sémantique CRUD
Niveau 3 : Hypermedia API
MODÈLE DE MATURITÉ DE RICHARDSON
Niveau 0
Niveau 1
Niveau 2
Niveau 3

13. Séparation des métiers
Mutualisation de la gestion des utilisateurs
Gestion centralisée de la liste des utilisateurs
Les APIs ne gèrent que des rôles
Standards d’authentification éprouvés
Throttling
SÉCURISATION

14. 03
AVEC QUOI CONCEVOIR UNE
API ?

15. APPLICATIONS NETWORK
« Des programmes qui effectuent une seule chose […] et qui collaborent »

16. API-LED CONNECTIVITY

17. LIFECYCLE OF AN API DESIGN

18. MERCI
Démonstration
https://bit.ly/3BYWwr7

19. Straight to
the point
www.spikeelabs.fr