REST
------
Ensemble de contraintes architecturales que les développeurs d'API peuvent mettre en œuvre de différentes 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 est fournie via le protocole HTTP dans l'un des formats suivants : JSON, HTML, XLT, Python, PHP ou texte brut.
Le langage le plus communément utilisé est JSON.
IMPORTANT : les en-têtes et paramètres jouent un rôle majeur dans les méthodes HTTP d'une requête HTTP d'API RESTful, car ils contiennent des informations d'identification importantes concernant la requête : métadonnées, autorisation, URI, mise en cache, cookies, etc.
Une API RESTful doit remplir les critères suivants :
- ARCHITECTURE CLIENT-SERVEUR : Les clients de l’API utilisent des appels HTTP pour demander une ressource (une méthode GET) ou envoyer des données au serveur (une méthode POST), ou l’une des autres méthodes HTTP prises en charge par l’API. GET et POST sont les méthodes les plus fréquemment utilisées, mais d’autres méthodes comme HEAD, PUT, PATCH, DELETE, CONNECT, OPTIONS ET TRACE peuvent également être prises en charge.
- SANS ETAT (stateless) : Une application sans état ne maintient pas de connexion ni ne stocke d’informations entre deux requêtes du même client. Un client fait une requête, l’API exécute l’action définie dans la requête et répond. Une fois que l’API a répondu, elle se déconnecte et ne conserve aucune information sur le client dans sa mémoire active. L’API traite chaque requête comme une première demande.
- MISE EN CACHE : La possibilité de mettre en cache des données afin de limiter la bande passante
- INTERFACE UNIFORME : entre les composants qui permet un transfert standardisé des informations Cela implique que :
=> les ressources demandées soient identifiables et séparées des représentations envoyées au client ;
=> les ressources puissent être manipulées par le client au moyen de la représentation reçue, qui contient suffisamment d'informations ;
=> 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 ;
=> 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 de hiérarchiser les différents types de serveurs (pour la sécurité, l'équilibrage de charge, etc.) impliqués dans la récupération des informations demandées
- 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
Bien que l'API REST doive répondre à l'ensemble de ces critères, elle est considérée comme étant plus simple à utiliser qu'un protocole tel que SOAP (Simple Object Access Protocol), qui est soumis à des contraintes spécifiques, dont la messagerie XML, la sécurité intégrée et la conformité des transactions, ce qui le rend plus lourd et moins rapide.
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.
