pressmaster - Fotolia

Quels sont les types d'API et leurs différences ?

Les entreprises s'appuient de plus en plus sur les API pour interagir avec leurs clients et partenaires. Tout commence par savoir quel type d'API est adapté à vos besoins.

L’API est un moyen puissant et polyvalent de connecter des applications et programmes divers et variés. Ces interfaces permettent à un large éventail de produits logiciels et de composants d’interagir ainsi que d’échanger des données. Avec les API, les programmeurs peuvent aussi ajouter des caractéristiques et des fonctionnalités aux services qu'ils construisent.

Cependant, les API ne sont pas toutes égales. Les développeurs peuvent travailler avec un assortiment de types d’API, de protocoles et d’architectures qui répondent aux besoins uniques de différentes applications et entreprises.

Quatre types d’API Web

Les interfaces de programmation sont largement acceptées et utilisées dans les applications Web. Il existe quatre principaux types d’API couramment employés dans ce contexte : publique, partenaire, privée et composite.

API publiques. Une API publique est ouverte et disponible pour être utilisée par tout développeur ou acteur tiers. Une entreprise qui cultive une stratégie commerciale impliquant le partage de ses applications et de ses données avec les autres sociétés développera et offrira une API publique.

Les API publiques supposent généralement une authentification et une autorisation modérées. Une entreprise peut également chercher à monétiser l’API en imposant un coût par appel pour employer l’API publique.

API partenaires. Une API partenaire, uniquement disponible pour des développeurs externes ou des consommateurs d’API spécifiquement triés et autorisés, est un moyen de faciliter les activités interentreprises. Par exemple, si une organisation souhaite partager certaines de ses données clients avec des spécialistes de la gestion de la relation client (CRM), une API partenaire peut connecter le système interne de données clients à ces parties tierces. En revanche, aucun autre usage de l’API n’est permis.

Les partenaires disposent de droits et de licences clairs pour accéder à ces interfaces. Pour cette raison, les API partenaires intègrent habituellement des mécanismes d’authentification, d’autorisation et de sécurité plus robustes. Les groupes ne monétisent généralement pas ces API directement : les partenaires sont rémunérés pour leurs services plutôt que par l’utilisation des API.

API internes. Une API interne (ou privée) est destinée à être utilisée uniquement au sein de l’entreprise, pour connecter des systèmes et des données. Par exemple, une API interne peut connecter les systèmes de paie et RH d’une société.

Les API internes présentent traditionnellement une sécurité et une authentification faibles, voire inexistantes, parce qu’elles ne sont pas exposées publiquement et que ces niveaux de sécurité sont supposés dépendre d’autres couches ou de politiques séparées. Cette situation est toutefois en train de changer, car la sensibilisation accrue aux menaces et les exigences de conformité réglementaire influencent de plus en plus la stratégie des organisations en matière d’API.

API composites. Les API composites combinent généralement deux ou plusieurs interfaces de programmation pour établir une séquence d’opérations connexes ou interdépendantes. Les API composites peuvent être utiles pour traiter des comportements complexes ou étroitement liés, et peuvent parfois améliorer la vitesse et les performances par rapport aux API individuelles.

Protocoles et architectures d’API

Les API échangent des commandes et des données, ce qui nécessite des protocoles et des architectures clairs – des règles, des structures et des contraintes. Aujourd’hui, il existe trois grandes catégories de protocoles ou d’architectures API : REST, RPC et SOAP. On peut les qualifier de « formats », chacun présentant des caractéristiques et des inconvénients spécifiques. Ils sont utilisés à des fins différentes.

REST. L’architecture REST (representational state transfer) est peut-être l’approche la plus populaire pour construire des API. REST s’appuie sur une relation client-serveur qui sépare les parties front et back-end de l’API et offre une flexibilité considérable en matière de développement et de mise en œuvre. REST est « stateless », ce qui signifie que l’API ne stocke aucun état ou donnée entre les requêtes. REST prend en charge la mise en cache, qui stocke les réponses pour les API lentes ou non sensibles au temps. Les API REST, généralement appelées « API RESTful », peuvent également communiquer directement ou fonctionner par le biais de systèmes intermédiaires tels que les passerelles API et les équilibreurs de charge.

RPC. Le protocole d’appel de procédure à distance (RPC) est un moyen simple d’envoyer plusieurs paramètres et de recevoir des résultats. Les API RPC invoquent des actions ou des processus exécutables, tandis que les API REST échangent principalement des données ou des ressources telles que des documents. Les RPC peuvent être codés en deux langages différents, JSON et XML ; ces API sont appelées respectivement JSON-RPC et XML-RPC.

SOAP. Le protocole SOAP (au départ, un acronyme de Simple Object Access Protocol, ce qui n’est plus le cas aujourd’hui) est une norme de messagerie définie par le World Wide Web Consortium et utilisée pour créer des API Web, généralement écrites en XML. SOAP prend en charge un large éventail de protocoles de communication que l’on trouve sur Internet, tels que HTTP, SMTP et TCP. SOAP est également extensible et indépendant du style, ce qui permet aux développeurs de concevoir des API SOAP de différentes manières et d’ajouter facilement des caractéristiques et des fonctionnalités. L’approche SOAP, par le biais de l’IDL Web Services Description Language (WSDL), détermine la manière dont le message est traité, les fonctionnalités et les modules inclus, le ou les protocoles de communication pris en charge et les messages SOAP sont écrits.

Contrairement à REST, SOAP est une norme très structurée, étroitement contrôlée et clairement définie. Par exemple, les messages SOAP peuvent contenir jusqu’à quatre composants, dont une enveloppe, un en-tête, un corps et un défaut (pour le traitement des erreurs).

REST ne dépend pas d’un IDL, mais de diverses spécifications. La plus répandue sur le marché n’est autre qu’OpenAPI (anciennement Swagger).

Le cas GraphQL

 Imaginé par les ingénieurs de Facebook, GraphQL est avant tout un langage de requête et un environnement d’exécution pensé comme une alternative à l’architecture REST. Inspirées du protocole RPC, les API GraphQL disposent de leur propre architecture basée sur un système de schéma de requêtes typé. Ces API permettent d’exposer uniquement les données souhaitées depuis le serveur vers le client, avec pour avantage une meilleure sécurité et des charges plus petites. Pour autant, GraphQL est une technologie beaucoup plus jeune. D’après un utilisateur, la complexité est reportée du côté serveur, alors que l’architecture REST est plus équilibrée dans ce fonctionnement. Pour d’autres, cette simplicité dépend d’une courbe d’apprentissage plus abrupte, mais particulièrement gratifiante.

Comparaison des protocoles d’API

Le choix d’un format d’API peut avoir un impact profond et durable sur le succès et l’adoption d’une API. Les organisations doivent sélectionner le format le plus approprié en fonction de la complexité des informations à échanger, du niveau de sécurité nécessaire autour de ces informations et de la vitesse ou des performances requises pour ces échanges.

Par exemple, un format plus simple peut être plus facile à coder et à maintenir, mais peut ne pas offrir le niveau de sécurité, tel que le chiffrement, qu’une entreprise utilisatrice exige. Des formats plus complexes pourraient offrir cette sécurité, mais présentent des courbes d’apprentissage plus élevées pour les adoptants ou exigent davantage de corrections de bugs et de travail de la part des développeurs. Le compromis est rarement simple, mais il existe des considérations communes aux principaux formats d’API.

Prenons l’exemple de REST et SOAP. Ces deux technologies sont conçues pour connecter des applications et utilisent principalement les protocoles et commandes HTTP tels que GET, POST et DELETE. Tous deux peuvent utiliser XML pour former les requêtes et les réponses. Cependant, SOAP dépend de XML par conception, tandis que REST peut également utiliser JSON, HTML et du texte brut. Toutefois, il faut bien noter la grande différence entre ces deux technologies. SOAP est un protocole d’échange de données XML, REST est un style d’architecture. SOAP est construit à partir d’appels de procédures à distance, tandis que REST est basé sur des ressources.

Ainsi, REST et SOAP échangent tous deux des informations, mais le font de manière très différente. SOAP est utilisé lorsqu’une entreprise exige des règles clairement définies pour supporter des échanges de données plus complexes et la possibilité d’appeler des procédures. De ce fait, SOAP est dit plus sécurisé puisqu’il s’appuie sur les protocoles WS-Security permettant de mettre en place un système de chiffrement et de signatures XML, en sus de jetons SAML. Il doit offrir authentification, intégrité, confidentialité et non-répudiation. Les API Rest supportent le protocole TLS, plus régulièrement mis à jour, mais celui-ci ne protège que la couche réseau. Les développeurs utilisent fréquemment SOAP pour les API internes ou celles des partenaires. Toutefois, SOAP est un protocole qui n’a pas été mis à jour depuis 2007 : les services qui en dépendent sont souvent des systèmes existants.

REST est employé pour des échanges rapides de données relativement simples. REST peut également permettre une plus grande évolutivité, en supportant des bases d’utilisateurs importantes et actives. Ces caractéristiques rendent REST populaire pour les API publiques, comme celles couplées à des applications mobiles.

REST SOAP
Fonctionne avec XML, JSON, HTTP et du texte Fonctionne avec XML par défaut
Directives souples et flexibles basées sur les architectures Règles strictes, clairement définies
Niveau de sécurité modeste Niveau de sécurité avancé
Traite correctement les données Traite correctement les processus (actions)
Utilise peu de bande passante est hautement extensible Utilise plus de bande passante et est moins scalable

Il est plus simple de savoir quand utiliser RPC. Comme SOAP, RPC est très structuré et destiné à des API relativement élémentaires capables d’invoquer des processus. Le choix se porte alors sur l’utilisation de JSON ou de XML – et là encore, cela dépend de l’objectif de l’API, des types d’informations à échanger et du niveau de sécurité requis. JSON est le langage le plus simple, et les JSON-RPC ne prennent en charge que les échanges de données alphanumériques (texte) avec peu de sécurité. XML-RPC traite un plus large éventail de données, notamment du texte, des images, des graphiques et des diagrammes, etc. Ainsi, XML offre des capacités supérieures de manipulation de documents et propose de meilleures fonctionnalités de sécurité que JSON. Les deux approches prennent en charge une variété de langages de programmation, notamment Python, Java et PHP.

Le cas gRPC

Ce framework imaginé et libéré par Google réinterprète le protocole RPC pour sérialiser et désérialiser des messages légers via HTTP/2. Les messages sont encodés en Protobuf (Protocol Buffer), un IDL équivalent de XML ou de JSON avec davantage de types binaires. Son grand avantage est de créer des liaisons client-serveur multiplateforme en de multiples langages. Avec sa manière particulière d’implémenter des API RPC, Google Remote Procedure Call peut gérer des requêtes en parallèle et des communications bidirectionnelles en temps réel. Très utilisé dans les architectures de microservices ou pour administrer la synchronisation de données entre un back-end et plusieurs clients, gRPC est aussi employé pour générer automatiquement des librairies client pour des applications iOS et Android. Avantage et inconvénient à la fois, les messages ne sont pas lisibles par les humains. Ce framework demande généralement d’installer un proxy entre le client et le serveur et ne supporte pas tous les navigateurs Web.

En fin de compte, les API basées sur RPC sont un mauvais choix pour les échanges de données en raison de leur prise en charge restreinte des types de données et de leur sécurité limitée. Toutefois, elles peuvent convenir à certaines API composites internes. Par exemple, les API JSON-RPC peuvent effectuer des appels sans attendre de réponse et supporter plusieurs appels simultanés qui peuvent être traités de manière asynchrone.

 

Pour approfondir sur API

Close