A l’heure actuelle, les API REST sont partout. Dans la vie de tous les jours, cela se matérialise par vos commandes de livraisons de repas,vos achats en ligne, écouter de la musique,streaming… Pour faire simple elles connectent un frontend avec un backend.
Qu’est ce qu’une API ?
API veut dire : Application Programming Interface.
Cela fournit une communication entre un client (votre frontend) et un fournisseur(votre API).
Il existe des documents qui décrivent comment construire ou développer ce type d’interfaces et ceux-ci se nomment les spécifications.
Le terme API correspond autant à la spécification qu’à l’implémentation.
Et REST API ?
A la différence des WebServices SOAP , il n’y a pas de documentation officielle pour les API RESTFul.
Ceci est du au fait que SOAP est un protocole et que REST est un type « d’architecture » destinée à améliorer la performance, la scalabilité, la modularité…
Tout cela est accompli via des principes et non des règles établies comme l’architecture client-serveur , l’usage de cache , l’architecture en couches et des interfaces uniformes.
Et les bonnes pratiques ?
Je vais essayer de détailler des pratiques usuelles et admises comme standard ci-dessous.
Le nommage des endpoints
Imaginons que votre endpoint d’API concerne des utilisateurs , il faudra le nommer /users et non pas /createuser ou /getusers .
Pour les différentes actions, il faudra privilégier l’utilisation des différents verbes HTTP :
- Pour créer un utilisateur : l’endpoint sera /users avec une action en POST.
- Pour récupérer les utilisateurs : l’endpoint sera toujours /users avec une action en GET.
Utiliser les bonnes méthodes ou verbes
Cela recoupe avec le point ci-dessus mais il est important d’utiliser les bons verbes pour que tout le monde comprenne l’intention en lisant vos définitions d’API.
Versionner proprement les API
Le versionning, en cas d’évolution rapide de votre API sera très important si les consommateurs ne se mettent pas à jour au même rythme.
Il est essentiel que tout le monde puisse consommer vos API sans régressions quand vous les faites évoluer.
Par exemple, le client doit pouvoir toujours consommer la V1 sans régression tout en ayant conscience qu’une V2 existe par exemple.
Utiliser les codes HTTP standard
Les API REST utilisent des protocoles HTTP, il est donc logique de renvoyer des codes HTTP standard comme 200 pour un succès, 404 pour « Not found » etc
Ces codes étant standards, tout le monde les comprendra.
Considérer l’aspect sécurité
Il est important de protéger son API. On ne parle que d’autorisations ici même si il faut bien sur sécuriser son API avec par exemple des tokens JWT et utiliser la communication en HTTPS.
Limiter le nombre de requêtes par seconde via les middleware en .NET permet de protéger son serveur d’une attaque DDoS par exemple.
La documentation
On néglige souvent l’apport de la documentation mais elle permettra à tout le monde de comprendre l’intention de chaque action, la consommer de la bonne façon etc
Pour cela, les pratiques recommandent Swagger qui est généralement inclus dans tous les projets de création d’API par défaut.
Ces pratiques ne sont pas exhaustives mais elles permettent au minimum d’avoir quelque chose de propre et qui respectent un certain standard admis comme bon.
Si vous souhaitez aller plus ==> https://restfulapi.net/
Happy coding ! 😎
Articles similaires