Basiquement, l’API ou Application Programming Interface d’une application est un ensemble de fonctionnalités organisé et structuré qui peut être mis à disposition d’autres programmes.
Il existe deux principaux types d’API :
Ici, c’est les API dites Webservices qui nous intéressent, mais stay tuned : prochainement nous évoquerons plus en détail les premières :)
Dans l’univers du web, le point de départ, c’est le SOAP. Il s’agit d’un protocole HTTP mis au point à la fin des années 90. Exclusivement basé sur le XML, ce protocole permet de structurer fortement les échanges mais il a un très gros inconvénient : le poids des flux échangés. En effet, le XML est très verbeux. A titre d’exemple, pour récupérer une liste de vols pour une destination, nous pouvons facilement atteindre les 500 voir 1 000 Ko (1 méga)... c’est juste énorme. Ceci-dit, et nous le voyons tous les jours, le XML permet de contrôler les flux notamment avec les namespaces qui représentent une forme de modèle de validation.
Il existe du coup une alternative intéressante, le REST. Mis au point en 2000 par Roy Fielding c’est plus simple, moins structuré mais beaucoup, beaucoup plus léger, basé sur le JSON, et qui peut également retourner d’autres formats : JSON, XML, HTML, CSV… Autre point important, le JSON (JavaScript Object Notation) offre l’énorme avantage d’être directement interprété par le javascript, langage devenu universel avec la mort de Flash et l’arrivée des applications All-in-One.
Mon opinion ? Le SOAP est devenu une solution trop contraignante. A cause du poids des flux XML, il est impensable de s’en servir pour échanger des informations avec un smartphone sur un réseau GSM où le débit peut être très limité. C’est pourquoi, nous privilégions systématiquement les API REST… Mobile first ;)
SOAP vs REST : les principales différences ?
REST et SOAP sont des éléments souvent comparés l'un à l'autre dans la conception des applications client-serveur, mais c'est une erreur.
http://www.journaldunet.com/web-tech/developpement/1202749-soap-vs-rest-les-principales-differences/
Prenons un exemple : vous souhaitez créer une application mobile pour publier des offres que vos clients pourront acheter directement sur leur smartphone.
Le smartphone ne dispose que du catalogue, et encore, si vous vendez des voyages, vos clients devront interroger votre système d’informations pour savoir quel est le prix et si il y a de la disponibilité pour des dates données.
Du coup, votre application mobile doit pouvoir interroger votre programme de gestion. C’est là que les API REST entrent en jeu. L’application mobile va transmettre une requête à l’API qui va la traiter et retourner une réponse qui sera interprétée et s’affichera sur l’interface du smartphone.
A ce stade, on pourrait se dire que n’importe qui peut accéder à vos informations. Oui ... et non.
Dans ce cas, il existe plusieurs moyens de sécuriser les accès. Parmi les plus connus et utilisés, nous pouvons trouver différents protocoles d’identification :
Pour la petite histoire, l’Oauth a été mis en place par un groupe de travail au sein de Twitter au milieu des années 2000. Par la suite, de nombreuses autres entreprises ont suivi telles que Google, Facebook, Slack, Salesforce et bien d’autres.
Rajoutons un brin de complexité pour celles et ceux qui suivent encore :)
Au niveau des API REST, il existe deux principaux types de requêtes :
Souvenez-vous, lorsque nous parlions du SOAP qui offre un avantage particulier offert par l’utilisation du XML et des namespaces… Nous aurions pu penser que les API REST étaient limitées de ce point de vue… C’était sans compter l’apport d’un code source bien fait qui vérifie les valeurs transmises, voire la nature des objets et qui peut détecter des erreurs.
Subvitamine accompagne les PME & ETI afin d'identifier leurs enjeux et de proposer des solutions digitales adaptées et innovantes, multipliant leurs performances.