API, communication en temps réel

Le serveur ne peut pas faire de requêtes, mais il existe des moyens de savoir où en est notre pizza ! Brian Cooksey nous dit tout sur l'intégration et les webhooks.

Par

Dans l'article précédent, nous avons appris comment concevoir une API en en construisant une nous-mêmes et en explorant quelques exemples bien réels. À ce stade de notre apprentissage, nous avons des connaissances solides et il est temps qu'elles commencent à porter leurs fruits. Nous sommes prêts à voir comment nous pouvons faire travailler les API pour nous. Dans cet article nous allons apprendre 4 façons de réaliser une communication en temps réel avec des API.

Intégrations

Pour bien planter le décor, rappelons-nous à quoi nous servent les API. Dans notre premier article, nous avons dit que les API facilitent l'échange de données entre deux systèmes (sites web, desktops, smartphones). Cette simplicité d'échanges nous permet de lier des systèmes entre eux pour former une intégration. L'intégration nous rend la vie plus facile, c'est pourquoi elle est appréciée : vous pouvez faire quelque chose dans un système, l'autre sera mis à jour automatiquement.

Pour notre propos, nous allons partager les intégrations en deux grandes catégories. Dans la première, que nous appellerons client-driven (“pilotée par le client”), c'est une personne qui interagit avec le client et qui veut que les données du serveur soient mises à jour. Dans la seconde, server-driven (“pilotée par le serveur”), quelqu'un fait quelque chose sur le serveur et souhaite que le client soit averti du changement.

L'intérêt de diviser les intégrations de cette manière est simple : le client est le seul qui peut initier une communication. Rappelez-vous, c'est le client qui fait les requêtes, le serveur ne fait que répondre. En conséquence de cette limitation, les changements sont faciles à envoyer du client au serveur, mais difficiles dans l'autre sens.

Intégration client-driven

Pour démontrer la facilité des intégrations pilotées par le client, revenons à notre chère pizzeria et à son API de commande de pizzas. Nous venons de lancer une appli pour smartphone qui utilise cette API. Dans ce scénario, la pizzeria est le serveur et l'appli smartphone est le client. Un consommateur utilise l'appli pour choisir une pizza et clique sur le bouton pour envoyer sa commande. Dès que le bouton est cliqué, l'appli sait qu'elle doit envoyer une requête à l'API de notre pizzeria.



Figure 1 - Exemple d'interaction pilotée par le client

Plus généralement, quand une personne interagit avec le client, celui-ci sait exactement quand les données changent, il peut donc appeler immédiatement le serveur pour le lui faire savoir. Il n'y a pas de délai (il est en temps réel) et le process est efficace parce qu'il suffit d'une requête pour chaque action.

Intégration server-driven

Une fois la commande passée, le consommateur voudra sans doute savoir quand sa pizza est prête. Comment utilisons-nous l'API pour lui envoyer des infos à jour ? Eh bien, là ça devient plus difficile. Ce n'est pas le consommateur qui fait la pizza, il attend simplement que la pizzeria prépare sa commande et mette à jour le statut de la commande (bien reçue, en cours de préparation, terminée, livraison en cours), en d'autres termes les données évoluent du côté serveur et le client a besoin d'en être informé. Oui mais voilà, si le serveur ne peut pas faire de requêtes, nous sommes coincés !

Pour résoudre ce problème, nous utilisons la seconde catégorie d'intégrations. Il y existe plusieurs solutions utilisées par les développeurs pour contourner les limitations des requêtes. Regardons chacune d'entre elles.

Polling

Si le client est le seul à pouvoir envoyer des requêtes, la solution la plus simple pour lui de se tenir au courant est d'envoyer des demandes de mise à jour au serveur. Il peut le faire en faisant la même requête de façon répétée, une technique appelée polling (demande sélective).

Avec notre pizzeria, ça pourrait ressembler à ceci :

Figure 2 - Exemple de demande sélective pour connaître le statut de notre commande.

Dans cette approche, plus le client fait de demandes sélectives, plus la communication ressemble à du temps réel. Si le client demande toutes les heures, il y aura au pire une heure de retard entre un événement survenu du côté du serveur et la connaissance qu'en aura le client. S'il fait une demande toutes les minutes, le client et le serveur seront quasiment synchro.

Cette solution présente évidemment un gros inconvénient, c'est qu'elle est terriblement inefficace. La plupart des requêtes envoyées par le client le sont en vain car rien n'a changé du côté serveur. Pire, pour être mieux informé, l'intervalle doit être raccourci ce qui entraîne plus de requêtes et moins d'efficacité.

Long polling

Si les requêtes étaient gratuites, personne ne se soucierait de l'efficacité et on pourrait faire des demandes sélectives sans se préoccuper de rien. Malheureusement, gérer des requêtes a un coût. Pour qu'une API puisse traiter des requêtes plus nombreuses, elle doit utiliser plus de serveurs, ce qui coûte cher. Élargissez notre situation lourdaude aux proportions de Google ou de Facebook et vous imaginez le gâchis. C'est pourquoi beaucoup d'efforts ont été réalisés pour optimiser la façon dont un client peut recevoir des mises à jour de la part du serveur.

L'une d'entre elles, qui développe le système précédent, s'appelle long polling. Elle utilise la même idée de demandes répétées mais avec une approche originale. Le serveur ne répond pas immédiatement. Il attend que quelque chose change pour envoyer une réponse avec la mise à jour.

Revisitons notre exemple de demande sélective, mais cette fois avec un serveur qui utilise le “truc” :

Figure 3 - Exemple de long polling.

Cette technique est vraiment astucieuse. Elle obéit à la règle qui veut que ce soit le client qui fasse la requête initiale, tout en s'appuyant sur le fait qu'il n'existe aucune règle interdisant au serveur d'être lent à répondre. Aussi longtemps que le client et le serveur sont d'accord sur le fait que le serveur va bien traiter la requête du client, et que le client est capable de garder sa connection au serveur ouverte, ça marche.

Pour maligne que soit cette solution, elle présente elle aussi des inconvénients. Nous passerons sur les détails techniques, mais il subsiste des problèmes comme celui de savoir combien de requêtes le serveur peut garder sous le coude en même temps, ou celui de savoir comment retrouver le fil si la connection tombe. Pour l'heure, disons qu'aucune des formes de polling n'est satisfaisante.

Webhooks

Le polling étant exclu, quelques développeurs innovants se sont dit “si notre problème vient du fait que seul le client peut faire des requêtes, pourquoi ne pas supprimer cette règle ?” et ils l'ont fait. Le résultat est ce qu'on appelle des webhooks, une technique dans laquelle le client fait des requêtes et reste à l'écoute, ce qui permet au serveur d'envoyer facilement des mises à jour.

C'est de la triche, direz-vous, maintenant le serveur fait des requêtes au client ! Rassurez-vous, on ne vous a pas raconté de bobards, ce qui fait fonctionner le webhook, c'est que le client devient à son tour un serveur ! D'un point de vue technique, il est parfois très facile d'étendre les fonctionnalités du client pour qu'il soit à l'écoute des requêtes, ce qui permet une communication dans les deux sens.

Regardons le fonctionnement basique des webhooks. Dans leur forme la plus simple, les webhooks imposent au client de fournir une URL de Callback, où il peut recevoir des événements, et imposent au serveur d'avoir un endroit où une personne peut entrer cette URL de Callback. Dès lors, quand quelque chose change au niveau du serveur, celui-ci peut envoyer une requête à l'URL de Callback pour informer le client.

Pour notre pizzeria, le flux ressemblerait à ceci :

Figure 4 - Utilisation de webhooks pour recevoir des mises à jour (Zapier étant le client).

Cette solution est excellente. Les changements intervenus sur le serveur sont envoyés instantanément au client, dans une véritable communication en temps réel, et les webhooks sont efficaces car il n'y a qu'une seule requête par mise à jour.

Abonnements webhooks

En partant de cette idée de webhooks, tout un tas de solutions sont nées qui visent à mettre en place un processus dynamique afin d'éviter à une personne d'entrer manuellement une URL de Callback sur le serveur. Vous avez peut-être entendu parler de HTTP Subscriptions Specification, Restful Webhooks, REST Hooks et PubSubHubHub. Ce que font toutes ces solutions, c'est essayer de définir un processus d'abonnement où le client peut indiquer au serveur quels événements l'intéressent et à quelles URL de Callback envoyer les mises à jour.

Chaque solution comporte une approche légèrement différente, mais le flux général ressemble à ceci :

Figure 5 - Requêtes nécessaires pour les abonnements Webhooks.

Les webhooks basés sur abonnement ont un avenir prometteur. Ils sont efficaces, en temps réel, et d'utilisation facile. Tout comme REST, dont le taux d'adoption est en pleine explosion, une véritable marée monte actuellement et les API sont toujours plus nombreuses à supporter une forme ou une autre de webhooks.

Cependant, il y autra toujours de la place pour le polling et le long polling dans un avenir proche. Tous les clients ne peuvent pas se comporter comme des serveurs, le meilleur exemple étant les smartphones dont les limitations techniques excluent la possibilité de webhooks. Mais avec les progrès de la technologie, des nouvelles idées se feront jour pour rendre la communication en temps réel plus aisée entre tous les appareils.

Récapitulation

Dans cet article nous avons séparé les intégrations en deux grandes catégories, pilotées par le client ou par le serveur. Nous avons vu comment les API peuvent être utilisées pour fournir des mises à jour en temps réel entre deux systèmes, et quels défis restent à relever.

Les termes-clés que nous avons rencontrés sont :

Polling : Faire une requête de façon répétée, à intervalles rapprochés
Long Polling : Polling, mais avec une réponse différée; améliore l'efficacité
Webhooks : Lorsque le client donne au serveur une URL de Callback, afin que le serveur puisse envoyer une mise à jour en temps réel
Abonnements webhooks : Nom informel de solutions permettant l'automatisation de la mise en place des webhooks


Liste des articles parus :


original paru le dans Zapier.com.

Sur l'auteur : travaille chez Zapier.com, vous pouvez le suivre sur Twitter ainsi que Zapier.

Traduit avec l'aimable permission de Zapier et de l'auteur.
Copyright Zapier © 2014.