API et Webhooks : quelle est la différence ?

Les API et les webhooks permettent à différents systèmes logiciels de synchroniser et de partager des informations. Les applications logicielles étant de plus en plus interconnectées, il est essentiel que les développeurs comprennent la différence entre ces deux moyens de partage des données et sélectionnent l'outil qui répond le mieux aux besoins de la tâche à accomplir.

Qu'est-ce qu'une API ?

Une API est comme un portail par lequel des informations et des fonctionnalités peuvent être partagées entre deux services logiciels. Le mot « interface » est essentiel pour comprendre l'objectif d'une API. Tout comme un navigateur Web est une interface permettant à un utilisateur final humain de recevoir, d'envoyer et de mettre à jour des informations sur un serveur Web, une API est une interface qui fournit des logiciels dotés des mêmes fonctionnalités.

Il existe différents types et catégories d'API (que nous explorerons plus loin), mais définies de manière générale, les API constituent le moyen le plus courant pour les différents systèmes logiciels de se connecter et de partager des informations. À l'heure actuelle, Programmable on the Web fournit une base de données de plus de 23 000 API qui traitent de tout, des données épidémiologiques mondiales aux blagues sur les pères. Chaque API est une toile vierge qui attend que les développeurs l'associent à d'autres applications et l'utilisent de manière innovante et créative.

Qu'est-ce qu'un webhook ?

Un webhook peut être considéré comme un type d'API piloté par des événements plutôt que par des requêtes. Au lieu qu'une application fasse une demande à une autre pour recevoir une réponse, un webhook est un service qui permet à un programme d'envoyer des données à un autre dès qu'un événement particulier se produit. Les webhooks sont parfois appelés « API inversées », car la communication est initiée par l'application qui envoie les données plutôt que par celle qui les reçoit. Les services Web étant de plus en plus interconnectés, les webhooks sont de plus en plus considérés comme une solution légère permettant d'activer des notifications en temps réel et des mises à jour de données sans avoir à développer une API complète.

Supposons par exemple que vous souhaitiez recevoir des notifications Slack lorsque des tweets mentionnant un certain compte et contenant un hashtag spécifique sont publiés. Au lieu que Slack demande continuellement à Twitter de nouvelles publications répondant à ces critères, il est beaucoup plus logique que Twitter n'envoie une notification à Slack que lorsque cet événement a lieu. C'est le but d'un webhook : au lieu d'avoir à demander les données à plusieurs reprises, l'application destinataire peut rester les bras croisés et obtenir ce dont elle a besoin sans avoir à envoyer des demandes répétées à un autre système.

Les API permettent des intégrations robustes

Une caractéristique importante des API est qu'elles fournissent une communication bidirectionnelle entre différents logiciels via un cycle demande-réponse, le plus souvent à l'aide du Protocole HTTP. Dans un cas d'utilisation typique d'une API, un logiciel demande un ensemble de données spécifique à un autre à l'aide d'une requête HTTP GET. À condition que la demande soit valide, le système récepteur répondra avec les données demandées dans un format lisible par machine, généralement XML ou JSON. C'est ce qui permet aux applications de partager des données indépendamment de leurs langages de programmation individuels ou de leurs spécifications internes. La nature universelle des interactions API peut permettre d'innombrables scénarios, qu'un utilisateur d'iPhone vérifie la température locale via le API AccuWeather à un chauffeur Uber qui navigue vers son prochain lieu de prise en charge via l'API Google Maps.

Outre la réception de données, les API peuvent également gérer toute la gamme des opérations « CRUD » (créer, lire, mettre à jour et supprimer) entre deux applications. En d'autres termes, les API ne servent pas uniquement à afficher des données à un utilisateur dans une interface, elles peuvent également être utilisées pour les modifier dans l'application où elles sont stockées. C'est ainsi que les API permettent aux systèmes logiciels d'étendre leurs services et leurs fonctionnalités, et de s'intégrer à d'autres plateformes de manière plus complète et plus significative.

La polyvalence des API en fait de puissants outils permettant aux développeurs d'étendre les fonctionnalités de leurs applications. La plupart des services Web modernes incluent des API qui permettent d'intégrer leurs données et fonctionnalités à d'autres outils. En fait, il serait rare de rencontrer un service Web d'entreprise qui n'exploite pas dans une certaine mesure une API d'au moins une autre application.

Les Webhooks permettent un partage de données léger

On pourrait penser que les webhooks étant des événements en temps réel, ils sont techniquement difficiles à implémenter. En fait, l'un des principaux avantages des webhooks est qu'ils sont plus faciles à configurer et consomment moins de ressources que les API. La création d'une API est un processus complexe qui, dans certains cas, peut être aussi difficile que la conception et la création d'une application elle-même, mais la mise en œuvre d'un webhook nécessite simplement de configurer une seule requête POST sur le côté expéditeur, d'établir une URL sur le côté récepteur pour accepter les données, puis d'effectuer une action sur les données fois qu'elles sont reçues.

Parmi les cas d'utilisation courants des webhooks, citons l'envoi de nouvelles inscriptions à des listes de courrier électronique et de désinscription à un système CRM, la mise à jour automatique du logiciel de comptabilité lorsque les factures sont payées ou la configuration de tout type de notifications. Dans chacun de ces types d'événements, les informations circulent dans une seule direction et aucune demande n'est nécessaire pour recevoir des données mises à jour.

Les mêmes caractéristiques qui rendent les webhooks relativement faciles à implémenter sont également les raisons pour lesquelles ils sont beaucoup plus limités que les API. La mise à jour des données fournies par un webhook nécessite de le reconfigurer entièrement pour écouter un événement différent. Dans la plupart des cas, il serait plus efficace de créer un nouveau webhook. Lorsque deux systèmes partagent des données via une API avec plusieurs terminaux, le système récepteur a accès à un éventail beaucoup plus large de données provenant du système expéditeur. De plus, contrairement aux API, les webhooks ne permettent pas au système expéditeur d'ajouter, de mettre à jour et de supprimer des données du côté récepteur. C'est pourquoi les webhooks seuls sont trop limités pour offrir une intégration complète entre deux applications.

Architecture des API : présent et futur

Les API appartiennent à différentes catégories en fonction des protocoles et des architectures qui définissent la manière dont elles envoient et reçoivent des données. Historiquement, le modèle architectural le plus courant pour la conception d'API était REST, en particulier pour ceux qui gèrent des applications Web.

REST est l'abréviation de « Representational State Transfer ». Ce schéma, défini par Roy Fielding en 2000, permet à deux applications de communiquer via HTTP de la même manière que les navigateurs et les serveurs. REST n'est pas une norme officielle. Il s'agit plutôt d'un ensemble de suggestions sur la manière de concevoir des API et d'autres services Web. Une API est considérée comme « RESTful » si sa conception respecte les recommandations suivantes :

• Client-Serveur: Tout comme un navigateur qui demande une page Web à un serveur, dans une API RESTful, l'application A envoie une requête à une URL hébergée sur l'application B via HTTP. L'application B évalue ensuite la demande et renvoie soit les données demandées, soit un message d'erreur.
• Apatride: le système répondant n'a pas besoin de connaître l'état de l'application du système qui fait la demande pour fournir une réponse appropriée. La demande à elle seule doit contenir toutes les informations nécessaires pour fournir la réponse.
• Possibilités de mise en cache: La réponse doit indiquer si le système récepteur est autorisé à le mettre en cache ou non.
• Systèmes en couches: L'API ne dépend pas d'un système particulier pour effectuer la demande afin de fournir la réponse. Cela signifie que le système demandeur peut être un client, un proxy ou tout autre intermédiaire.

C'est simple exemple convient aux conventions REST. Lorsque vous visitez l'URL, votre navigateur affiche une suggestion d'activité à laquelle vous pouvez participer si vous vous ennuyez au format JSON :

{
  "activity": "Go to a concert with some friends",
  "type": "social",
  "participants": 4,
  "price": 0.6,
  "link": "",
  "key": "4558850",
  "accessibility": 0.4
}

Quelle que soit la manière dont vous faites une demande à cette URL, que ce soit avec votre navigateur, avec BOUCLE, ou une bibliothèque cliente HTTP telle que aller chercher en JavaScript : L'API renverra le même objet. Outre REST, les autres conventions d'API incluent SAVON, COBRA et XML-RPC. À ce jour, REST est toutefois l'ensemble de directives d'architecture d'API le plus utilisé.

En 2015, l'équipe d'ingénierie de Facebook a publié GraphQL——un nouveau langage de requête pour les API destiné à fournir une alternative plus flexible à l'envoi de requêtes aux terminaux sur les API REST. Sans trop entrer dans les complexités de GraphQL, le principal avantage qu'il offre par rapport aux API REST traditionnelles est sa capacité à renvoyer les données exactes nécessaires à chaque requête tout en évitant la « surlecture » et la « sous-extraction », problèmes généralement rencontrés avec les API traditionnelles.

Par exemple, considérez la situation suivante. Une application d'évaluation de restaurants doit afficher les titres des avis les plus récents publiés par un utilisateur, ainsi que les trois dernières personnes à suivre cet utilisateur. À l'aide d'une API REST, le client doit généralement effectuer trois requêtes différentes à différents points de terminaison : une pour récupérer les données initiales de l'utilisateur, une seconde pour renvoyer tous les avis de cet utilisateur et une troisième pour renvoyer la liste des abonnés de cet utilisateur. À l'aide de GraphQL, un client pouvait accéder aux mêmes données en une seule requête répondant exactement aux exigences suivantes :

query {
    User(id: "qr3fsdcv24") {
        name
        posts {
            title
        }
        followers(last: 3) {
            name
        }
    }
}

Les API pour fonctionner dans mParticle

Les API sont le cheval de bataille de l'écosystème technique de mParticle. Ils contribuent en grande partie à ce qui permet à mParticle de compiler une vue omnicanale de vos clients et de partager ces profils avec les outils de votre stack marketing. Les plus de 280 intégrations directes de mParticle avec les principales solutions de marketing, d'analyse et d'entreposage de données sont toutes alimentées par des API personnalisées riches en fonctionnalités qui simplifient l'envoi de données en temps réel et de profils utilisateurs unifiés aux systèmes en aval.

Plutôt que de simples intégrations de webhooks, limitées à des flux de données unidirectionnels, les intégrations des partenaires de mParticle reposent sur des API complètes qui permettent une interaction beaucoup plus robuste entre les deux systèmes. Ces API sont toujours très actives dans les coulisses, comme lorsque les clients de mParticle dirigent de manière fluide le flux de leurs données dans l'interface utilisateur de mParticle, par exemple.

L'API Profile : interrogez directement vos profils utilisateur mParticle

Outre les API qui alimentent les intégrations entre partenaires, mParticle fournit aux développeurs des entreprises partenaires diverses API pour personnaliser leur collecte de données et personnaliser mParticle en fonction des besoins spécifiques de leur entreprise.

L'API Profile en est un exemple, qui permet aux clients de récupérer par programmation des profils utilisateur créés via les fonctionnalités de collecte de données multicanaux et de résolution d'identité de mParticle. Les données récupérées en interrogeant cette API peuvent aider les marques à créer rapidement des expériences personnalisées sur ou entre les canaux.

Voici un exemple de requête qui pourrait être envoyée à l'API Profile pour récupérer les données d'un profil utilisateur mParticle :

curl \
  -X GET \
  -H "Authorization: Bearer <access token>" \
"https://api.mparticle.com/userprofile/v1/<orgId>/<accountId>/<workspaceId>/
<mpid>?fields=device_identities,user_identities,user_attributes,
audience_memberships,attribution"

Et voici un exemple de réponse à cette demande :

{
   "mpid": 9080350317581165000,
   "created_timestamp_ms": 1574704283462,
   "last_stored_timestamp_ms": 1575301484215,
   "is_opted_out": false,
   "limit_ad_tracking": null,
   "device_identities": [
       {
           "type": "android_id",
           "encoding": "none",
           "value": "8789c459016a94b0"
       },
       {
           "type": "google_advertising_id",
           "encoding": "none",
           "value": "481c8a31-7d5d-4d96-93a0-2de7427167fc"
       }
   ],
   "user_identities": [
       {
           "type": "customer_id",
           "encoding": "none",
           "value": "Example-Customer-mxr15"
       },
       {
           "type": "email",
           "encoding": "none",
           "value": "Example-Customer-mxr15@example.com"
       }
   ],
   "account_userattributes": null,
   "user_attributes": {
       "view_preference": "Dark Mode",
       "tp_age": "18-34",
       "tp_gender": "male",
       "last_purchase_category": "Home Decor",
       "churn_risk_score": "4",
       "ltv": "342.1",
       "$city": "New York",
       "$state": "NY",
       "$country": "USA",
       "$firstname": "Marky",
       "$lastname": "Mark"
   },
   "audience_memberships": [
       {
           "audience_id": 17918,
           "audience_name": "Decor Remarketing",
           "expiration_timestamp_ms": null
       }
   ]
}

Pour explorer cette API plus en détail, vous pouvez l'expérimenter exemple d'application Node, qui appelle l'API mParticle Profile et renvoie le résultat à un client natif.

J'espère que cet article vous a permis de mieux comprendre ces deux méthodes courantes de partage de données entre applications. La même sagesse qui s'applique à toutes les architectures, frameworks, modèles de conception et technologies du génie logiciel vaut également pour les API et les webhooks : chaque chose a son heure et son lieu. La clé pour tirer le meilleur parti de ces deux outils est de savoir lequel convient le mieux à la tâche.