À propos des cookies sur ce site Pour fonctionner correctement, nos sites Internet nécessitent certains cookies (requis). En outre, d'autres cookies peuvent être utilisés avec votre consentement pour analyser l'utilisation d'un site, améliorer l'expérience des utilisateurs et à des fins publicitaires. Pour plus informations, passez en revue vos options de préférences en. En visitant notre site Web, vous acceptez que nous traitions les informations comme décrit dans ladéclaration de confidentialité d’IBM. Pour faciliter la navigation, vos préférences en matière de cookie seront partagées dans les domaines Web d'IBM énumérés ici.
Qu’est-ce qu’une API REST ?
Une API REST (également appelée API RESTful ou API Web RESTful) est une interface de programmation des applications (API) conforme aux principes de conception du style architectural REST (Representational State Transfer ). Les API REST offrent un moyen flexible et léger d’intégrer des applications et de connecter des composants dans des architectures de microservices .
Défini en 2000 par Roy Fielding, un informaticien, dans sa thèse de doctorat, REST offre aux développeurs un niveau relativement élevé de flexibilité, d’évolutivité et d’efficacité. Pour ces raisons, les API REST sont apparues comme une méthode courante permettant de connecter des composants et des applications dans une architecture de microservices.
Cet e-book démystifie les préjugés concernant l’observabilité et présente son rôle dans le monde numérique.
Principes de conception REST
Toutes les demandes d’API pour une même ressource doivent avoir la même apparence, quelle que soit la provenance de la demande. L’API REST doit garantir que le même élément de données, tel que le nom ou l’adresse e-mail d’un utilisateur, n’appartient qu’à un seul identifiant de ressource uniforme (URI). Les ressources ne doivent pas être trop volumineuses, mais doivent contenir toutes les informations dont le client pourrait avoir besoin.
Dans la conception d’API REST, les applications client et serveur doivent être complètement distinctes. La seule information que l’application cliente doit connaître est l’URI de la ressource demandée ; elle ne peut pas interagir avec l’application serveur d’une autre manière. De même, une application serveur ne doit pas modifier l’application cliente autrement qu’en lui transmettant les données demandées via HTTP.
Les API REST sont apatrides, ce qui signifie que chaque requête doit inclure toutes les informations nécessaires à son traitement. En d’autres termes, les API REST ne nécessitent aucune session côté serveur. Les applications serveur ne sont pas autorisées à stocker des données liées à une demande client.
Dans la mesure du possible, les ressources doivent pouvoir être mises en cache côté client ou serveur. Les réponses du serveur doivent également contenir des informations indiquant si la mise en cache est autorisée pour la ressource fournie. L’objectif est d’améliorer les performances côté client, tout en augmentant l’évolutivité côté serveur.
Dans les API REST, les appels et les réponses passent par différentes couches. En règle générale, il ne faut pas supposer que les applications client et serveur se connectent directement l’une à l’autre. Il peut y avoir un certain nombre d’intermédiaires différents dans la boucle de communication. Les API REST doivent être conçues de manière à ce que ni le client ni le serveur ne puissent dire s’ils communiquent avec l’application finale ou avec un intermédiaire.
Les API REST envoient généralement des ressources statiques, mais dans certains cas, les réponses peuvent également contenir du code exécutable (comme les applets Java). Dans ce cas, le code ne doit être exécuté qu’à la demande.
Les API REST communiquent via des requêtes HTTP pour exécuter des fonctions de base de données standard telles que la création, la lecture, la mise à jour et la suppression d’enregistrements (également appelées CRUD) au sein d’une ressource.
Par exemple, une API REST utilise une requête GET pour récupérer un enregistrement. Une requête POST crée un nouvel enregistrement. Une requête PUT met à jour un enregistrement et une requête DELETE en supprime un. Toutes les méthodes HTTP peuvent être utilisées dans les appels API. Une API REST bien conçue est similaire à un site Web exécuté dans un navigateur Web avec une fonctionnalité HTTP intégrée.
L’état d’une ressource à un instant donné, ou horodatage, est connu sous le nom de représentation de la ressource. Ces informations peuvent être fournies à un client dans pratiquement n’importe quel format, y compris JavaScript Object Notation (JSON), HTML, XLT, Python, PHP ou texte brut. JSON est populaire car il est lisible à la fois par les humains et les machines, et il ne dépend pas d’un langage de programmation.
Les en-têtes et paramètres de requête sont également importants dans les appels d’API REST, car ils contiennent des informations d’identification importantes telles que les métadonnées, les autorisations, les identifiants de ressources uniformes (URI), la mise en cache, les cookies, etc. Les en-têtes de requête et de réponse, ainsi que les codes d’état HTTP conventionnels, sont utilisés dans des API REST bien conçues.
Bien que la flexibilité soit un grand avantage de la conception d’API REST, cette même flexibilité facilite la conception d’une API défaillante ou peu performante. C’est pourquoi les développeurs professionnels partagent les bonnes pratiques en matière de spécifications d’API REST.
La spécification OpenAPI (OAS) établit une interface pour décrire une API de manière à permettre à tout développeur ou à toute application de la découvrir et de comprendre pleinement ses paramètres et ses capacités. Ces informations comprennent les points de terminaison disponibles, les opérations autorisées sur chaque point de terminaison, les paramètres d’opération, les méthodes d’authentification, etc. La dernière version, OAS3, comprend des outils pratiques, tels que le générateur OpenAPI, qui permettent de générer des clients API et des stubs de serveur dans différents langages de programmation.
La sécurisation d’une API REST commence également par les bonnes pratiques du secteur. Utilisez des algorithmes de hachage pour sécuriser les mots de passe et le protocole HTTPS pour sécuriser la transmission des données. Un cadre d’autorisation comme OAuth 2.0 peut aider à limiter les privilèges des applications tierces.
En utilisant un horodatage dans l’en-tête HTTP, une API peut également rejeter toute requête arrivant après un certain laps de temps. La validation des paramètres et les jetons Web JSON sont d’autres moyens de s’assurer que seuls les clients autorisés peuvent accéder à l’API.
Solutions connexes
Gérez le cycle de vie de vos API sur plusieurs clouds, stimulez la socialisation et optimisez vos efforts de monétisation dans l’ensemble de votre écosystème métier grâce à la gestion sécurisée des API d’IBM API Connect.
Connectez, automatisez et libérez le potentiel de votre entreprise grâce à des solutions d’intégration.
Connectez les applications, les données, les processus métier et les services, qu’ils soient hébergés sur site, dans un cloud privé ou au sein d’un environnement de cloud public.
Ressources
Découvrez comment les interfaces de programmation des applications, ou API, simplifient le développement de logiciels et l’innovation en permettant aux applications d’échanger des données et des fonctionnalités facilement et en toute sécurité.
Découvrez la gestion des API et comment une plateforme de gestion unifiée des API peut contribuer à l’évolution de votre organisation.
Lire le rapport 2023 Gartner Critical Capabilities sur la gestion du cycle de vie complet des API afin de découvrir pour quelles raisons Gartner a classé IBM parmi les leaders.