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

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).

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.

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.

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.