J’ai plus de 20 ans d’expérience dans le développement logiciel et l’architecture logicielle.
Les questions les plus déroutantes que je reçois habituellement sont : qu’est-ce que l’API et qu’est-ce que le service Web ? Quelles sont les différences? Sont-ils vraiment différents ? Pourquoi les services Web REST (transfert d’état représentatif) sont-ils appelés API ?
Dans le post suivant, je vais vous emmener dans un bref voyage à travers l’histoire de l’API pour répondre à ces questions, mais nous devons d’abord comprendre ce que signifie API.
Qu’est-ce que l’API ?
API est l’abréviation d’Application Programming Interface et, comme son nom l’indique, il s’agit d’une interface qui permet à un morceau de code d’interagir par programmation avec un autre morceau de code. Le morceau de code peut être une bibliothèque, une ressource, un composant ou même un système ou une application différente.
Les API peuvent être soit une API interne qui permet des interactions natives entre différentes parties de la même base de code d’application, comme l’appel d’une autre classe ou bibliothèque dans le même déploiement. D’autre part, l’API externe permet des interactions à distance, comme appeler un autre composant pour la même application déployée sur un environnement différent (pour les applications distribuées) ou même appeler une application totalement différente. Les interactions externes nécessitent une communication réseau supportée par un protocole réseau (tel que HTTP, JMS, TCP, etc.).
Si l’API (interne ou externe) est conçue avec soin, elle peut augmenter la réutilisabilité de la solution, masquer la complexité de l’implémentation et réduire les dépendances des clients vis-à-vis de l’implémentation interne, qui est censée améliorer la maintenabilité globale de la solution.
Dans le diagramme ci-dessous, l’interface appelée « SortI » est un exemple d’API interne native qui permet au code client d’effectuer la fonctionnalité de tri sans couplage direct avec l’implémentation sous-jacente.
API native pour le tri
Dans le diagramme ci-dessus, si nous décidons de changer l’implémentation de BubbleSort avec HeapSort, le client ne sera pas affecté étant donné que l’interface n’est pas modifiée.
Composants principaux de l’API
L’API se compose de trois composants principaux :
Faites défiler pour continuer
- Activités: C’est l’ensemble des actions et opérations fournies par l’interface. Par exemple, les méthodes définies dans l’interface java ou les opérations définies dans le fichier WSDL
- modèle de données: La structure de données pour l’entrée ou la sortie des opérations. Par exemple, les paramètres d’entrée et la structure de valeur de retour pour les opérations d’interface Java ou les schémas des messages d’entrée et de sortie WSDL.
- format de données: C’est le format qui définit la forme des données. Par exemple, le format binaire pour les API internes et le format SOAP pour les WS basés sur SOAP.
Historique des API
L’historique de l’API peut être divisé en quatre générations principales, comme illustré dans la chronologie ci-dessous :
Générations d’API
Selon le diagramme ci-dessus, la troisième génération d’API était l’API Web, qui avait deux styles principaux : WS basé sur REST et WS basé sur SOAP où les appels d’API distants ont été exécutés sur Internet en utilisant principalement le protocole HTTP.
Dans le diagramme suivant, nous allons approfondir l’histoire de la génération Web pour voir comment l’API Web a évolué au fil du temps.
La bonne question
Il est clair maintenant que la bonne question devrait être : quelle est la relation entre le service Web et l’API ? Et comme nous l’avons vu, le service Web n’est qu’un des types d’API.
À présent, vous vous demandez peut-être pourquoi les services Web REST sont appelés API ? La raison la plus probable était la haine des services Web SOAP par les adaptateurs REST, qui ont décidé de donner à ce style un nouveau nom qui n’a pas de « services Web » et évidemment pas de « SOAP » et finalement la décision a été de le nommer « REST API. » Avec le temps, c’est devenu juste « API » pour plus de simplicité, ce qui a causé beaucoup de confusion car il était difficile de savoir si nous parlions de l’API en général ou du REST WS en particulier.
En conséquence, et en tant que conseil général, assurez-vous, lorsque vous discutez des API, que l’auditeur sait de quel type d’API vous parlez.
Ce contenu est exact et fidèle au meilleur de la connaissance de l’auteur et ne vise pas à remplacer les conseils formels et individualisés d’un professionnel qualifié.
© 2022 Haitham Raik
