Qu’est-ce qu’une API ?

Ne pas confondre API et API :)

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 :

• Il y a les API que l’on peut considérer comme étant le dictionnaire des fonctionnalités d’un programme.
  Dans ce cas, nous pouvons également appeler ça un référentiel ;
• Et il y a les API dites Webservices qui représentent un ensemble de fonctionnalités pouvant être appelées par d’autres applications (les vôtres ou celles de partenaires) via Internet.

Ici, c’est les API dites Webservices qui nous intéressent, mais stay tuned : prochainement nous évoquerons plus en détail les premières :)

Les différentes natures d’API/webservices

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/

Fonctionnement d’une API REST

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.

• Oui, si vous pensez aux flux RSS dont le but est de diffuser une information maîtrisée.
• Non, si il s’agit d’une API pour des achats, voire du paiement en ligne.

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 :

• Le plus basique est une simple clé d’API : une simple chaîne de caractères spécifique à chaque application tierce.
• Plus compliqué, il y a l’Oauth ou l’Oauth2 : là, ça devient sécurisé car l’application qui souhaite accéder à votre API doit disposer à la d’une clé d’API, d’une clé secrète pour obtenir un jeton d’accès (ou token) qui sera communiqué à chaque appel.

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 :

• CRUD comme Create, Read, Update et Delete qui permet d'interagir avec vos modèles de données. Bien souvent, cela correspond basiquement aux tables de votre base de données ;
• RPC (Remote Procedure Call) qui va permettre d’appeler une procédure bien particulière.

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.