Qu'est-ce qu'une API REST ?

L'API REST est devenue l'API de service web la plus polyvalente et la plus utile. Sa simplicité, sa flexibilité et sa compatibilité la rendent idéale pour travailler avec différents types de données et interagir avec les principales applications disponibles sur le marché. Dans cet article, nous allons définir ce qu'est une API REST (ou RESTful) et la comparer à son prédécesseur, le protocole SOAP. En outre, nous examinerons leur fonctionnement et les raisons pour lesquelles la tendance à l'intégration dans le cloud rend les API REST si essentielles pour les entreprises aujourd'hui.

Qu'est-ce qu'une API REST ?

Une API REST (Representational State Transfer) ou RESTful est un type d'API, ou interface de programme d'application, qui aide les applications de services web à communiquer entre elles. Bien qu'elle soit théoriquement compatible avec n'importe quel protocole ou format de données, l'architecture REST utilise le plus souvent le protocole HTTP et transfère les données en utilisant JSON (JavaScript Object Notation). L'architecture REST est généralement retenue pour obtenir des données à partir du web en raison de sa flexibilité, de sa rapidité et de sa simplicité.

Jusqu'en 2000, le protocole SOAP (Simple Object Access Protocol), développé par Microsoft, était la plateforme la plus utilisée pour les interactions client-serveur. Si SOAP était à la fois utile et prisé, ce protocole présente deux inconvénients. Tout d'abord, ses utilisateurs doivent respecter des règles strictes concernant l'interaction avec le serveur. Deuxièmement, il repose sur le format XML,qui est assez fastidieux.

Insatisfait du protocole SOAP, l'informaticien Roy Fielding a proposé une alternative appelée « REST » pour sa thèse de doctorat en 2000. Les caractéristiques clés qui distinguent REST de son prédécesseur concernent la flexibilité de formatage, une vitesse accrue et une bande passante réduite. Aujourd'hui, REST compte parmi les types d'API les plus courants. Il est utilisé par la plupart des principaux fournisseurs web, notamment Amazon, Facebook, Twitter et Google.

Conception d'API REST

Comme toutes les API, REST permet de déplacer des données entre utilisateurs et applications. Par exemple, lorsque vous vous connectez à un site web ou accédez à une application sur votre téléphone, une API aide votre client à communiquer avec le serveur hôte. Les API sont le point de départ entre la livraison de vos requêtes au serveur et le renvoi de la réponse du serveur.

Demandes client

Le processus commence lorsqu'un client de l'architecture REST utilise des commandes HTTP pour envoyer des demandes au serveur. Par exemple, lorsque vous ouvrez une page web en saisissant une URL, vous envoyez une requête HTTP telle que « GET + URL ». De même, un client REST utilise ces types de commandes pour accéder aux informations que vous avez demandées. Les commandes HTTP les plus courantes sont les suivantes :

• GET - Récupération d'une ressource spécifiée
• POST - Création d'une nouvelle ressource
• PUT - Mise à jour d'une ressource existante
• DELETE - Suppression d'une ressource existante

Par exemple, la commande HTTP « GET https://api.bookseller.com/customers/ » récupère les noms de tous les clients du site web bookseller.

Réponse du serveur

Une fois la requête client initiée, l'API REST extrait les informations et envoie une réponse. Cela couvre une gamme de ressources comprenant des données, des images, des vidéos, des adresses web, des commentaires, des articles de blog, des tweets, etc. Lorsque le client demande une ressource au serveur, ce dernier n'envoie pas la ressource elle-même, mais répond en envoyant une représentation de cette ressource.

Ces réponses sont le plus souvent fournies au format JSON. Ce format est lisible par les humains comme par les machines. Sa compatibilité avec la plupart des langages de programmation en fait un choix idéal pour la flexibilité de l'API REST.

6 contraintes de l'API REST

L'un des principaux avantages de l'API REST porte sur la simplicité de sa syntaxe. Elle fonctionne selon un ensemble de règles de conception, appelées « contraintes ». Pour qu'une API soit considérée comme RESTful, elle doit respecter les six contraintes suivantes:

Interface uniforme

Une interface uniforme signifie que chaque client REST peut appeler le serveur et accéder à ses ressources de la même manière, qu'il s'agisse d'un navigateur, d'un code JavaScript ou d'une application mobile. Ceci est rendu possible par l'utilisation d'un URI (Unique Resource Identifier), qui est souvent une URL telle que « https://api.twitter.com/ ».

Les demandes et les réponses doivent être autosuffisantes : le client envoie toutes les informations dont le serveur a besoin pour traiter la demande, et le serveur y répond en fournissant les informations nécessaires pour modifier, supprimer ou simplement accéder à la ressource demandée.

Le serveur doit avoir la possibilité d'inclure des hyperliens qui permettent au client de modifier la ressource. Cette fonctionnalité est appelée « hypermédia en tant que moteur de l'état de l'application » (HATEOAS).

Architecture client-serveur

Dans l'architecture REST, les composants client et serveur sont clairement définis et séparés. Cette conception modulaire permet de changer ces deux composants indépendamment, sans impact sur l'autre composant. La plupart des clients et serveurs web sont conçus de cette manière. REST rend simplement cette contrainte explicite.

Apatridie

Dans une configuration RESTful, les interactions client-serveur sont sans état. Cela signifie que le serveur n'a pas besoin de se souvenir de l'état du client en le stockant en mémoire ou dans des bases de données. Par conséquent, toutes les informations requises par un serveur pour envoyer des données doivent être incluses dans une demande spécifique.

Cette absence d'état impose uniquement au client la responsabilité de maintenir l'état de l'application. Le serveur s'en trouve allégé, car il n'a pas besoin de stocker des données générales concernant les appels des clients pour répondre aux demandes futures.

Dans une architecture sans état, l'évolutivité est facilitée. Cependant, les clients peuvent être amenés à faire de multiples appels à un serveur pour obtenir des données, ce qui peut réduire les performances. En général, les développeurs web trouvent des moyens d'optimiser les performances des applications client en réduisant le nombre de sauts (hops) sur le serveur.

Système multicouche

Un système multicouche fait référence au découplage complet du client et du serveur. Lorsqu'une application cliente effectue une demande à l'adresse réseau du serveur, elle n'a pas besoin de connaître le serveur exact qui répond à sa demande. Il peut y avoir plusieurs couches de serveurs, chacune exécutant son propre ensemble de fonctions, telles que l'équilibrage de la charge, la mise en cache, etc., mais le client ignore toutes ces actions masquées.

La superposition ajoute une sécurité supplémentaire à l'API REST, car les attaques ou les évènements peuvent être isolés et contenus dans des couches individuelles. En outre, l'intégralité de l'architecture n'est jamais exposée.

Possibilité de mise en cache

Les serveurs REST peuvent mettre en cache des données. Grâce à l'en-tête Cache-Control, le serveur indique à son client si les données envoyées sont mises en cache (ou non) et la durée de validité de la réponse. Une fois la durée initiale expirée, le client envoie à nouveau un ping au serveur pour une mise à jour. Les numéros de version sont également utilisés par le client pour déterminer s'il possède la dernière version de la ressource demandée.

Code à la demande

Il s'agit de la seule contrainte facultative dans une configuration RESTful. Le code à la demande est une fonctionnalité qui permet au serveur d'envoyer un extrait de code que le client exécute ensuite de son côté. Par exemple, le code est envoyé en JavaScript dans une réponse HTML.

Différences entre le protocole SOAP et les API RESTful

Le débat entre REST et SOAP se poursuit depuis plus de vingt ans. Chaque interface a son utilité. Chacune présente ses propres forces et faiblesses. Bien que de nombreuses entreprises continuent d'utiliser le protocole SOAP, REST est devenu l'API la plus populaire en raison de son adaptabilité et de son architecture légère. Afin de comprendre ce qui distingue REST de SOAP, il est utile de comparer les deux :

SOAP est un protocole alors que REST est un type de conception. SOAP requiert des standards de communication et une syntaxe beaucoup plus stricts, tandis que REST ne pose que des directives architecturales de haut niveau (six contraintes), ce qui permet une plus grande flexibilité de mise en œuvre.

REST offre des performances plus rapides car il consomme moins de bande passante et de ressources. SOAP ne fonctionne qu'avec le format de données XML, ce qui entraîne des tailles de fichiers plus importantes. REST peut fonctionner avec des formats moins volumineux tels que HTML, JSON, et même du texte brut.

SOAP requiert une liaison plus étroite entre le client et le serveur. Lorsque la fonction serveur SOAP est invoquée, le client SOAP doit connaître la signature exacte de ces fonctions. Si la signature change, l'interface cesse de fonctionner.

Comme un client REST ne fait qu'appeler des noms de ressources, il n'a pas besoin de connaître les détails de mise en œuvre de l'API. Si le serveur modifie sa mise en œuvre, le client n'a aucune modification à apporter. REST permet ainsi d'atteindre un plus grand degré de séparation client-serveur que le protocole SOAP.

Les appels REST peuvent être mis en cache. La propriété de mise en cache des API REST signifie que les données peuvent être réutilisées par le navigateur web plutôt que d'effectuer de multiples appels au serveur. Il s'agit d'une option de conception plus sophistiquée, qui permet de conserver de la bande passante.

Le protocole SOAP est généralement considéré comme plus sûr. SOAP prend en charge les normes WS-Security et SSL. Il présente également une conformité intégrée à la norme ACID (Atomicité, Cohérence, Isolement, Durabilité), ce qui le rend plus adapté aux applications d'entreprise hautement sécurisées et aux systèmes qui traitent des données sensibles, comme les plateformes de paiement et les services de télécommunications. Toutefois, REST prend en charge les protocoles SSL et HTTPS.

API REST et intégration cloud

La tendance actuelle en matière de gestion des données est le passage à l'intégration dans le cloud. Les API permettent aux utilisateurs d'accéder aux informations stockées dans le cloud, sur plusieurs serveurs et dans divers formats. Bien que les API REST soient le plus souvent utilisées avec les plateformes SaaS (Software as a Service), elles jouent également un rôle important pour les fournisseurs PaaS (Platform as a Service). Parmi les fournisseurs les plus connus qui utilisent les API RESTful figurent Oracle, Jira, Google, Adobe, Amazon et GitHub.

Les enjeux de l'informatique dans le cloud étant considérables, les entreprises cherchent de plus en plus à s'assurer que leurs produits et services sont prêts à offrir toutes les fonctionnalités du cloud. Dans la plupart des cas, cela implique l'utilisation d'un outil d'intégration cloud qui fournit des connecteurs et des fonctionnalités API REST.

Les services cloud API de Talend simplifient le processus de création d'API, pour vous aider à tirer le meilleur parti de vos données. Grâce à un ensemble complet d'outils garantissant la qualité des données et plus de 900 connecteurs, vos API seront opérationnelles plus rapidement que jamais. Téléchargez une version d'évaluation gratuite dès aujourd'hui pour découvrir à quel point votre intégration peut être facile.