Cette page a été traduite par l'API Cloud Translation.

Fonctionnement du transfert

Matt Gaunt

Avant de nous intéresser à l'API, examinons le push de manière globale, du début à la fin. Ensuite, lorsque nous aborderons des sujets ou des API spécifiques plus tard, vous aurez une idée de la façon dont et pourquoi cela est important.

Voici les trois étapes clés pour implémenter le push :

Ajout de la logique côté client pour abonner un utilisateur aux notifications push (c'est-à-dire le code JavaScript et l'UI de votre application Web qui enregistre un utilisateur pour les notifications push).
Appel d'API à partir de votre backend / application qui déclenche un message push sur l'appareil d'un utilisateur.
Fichier JavaScript du service worker qui recevra un "événement push" lorsque le push arrivera sur l'appareil. C'est dans ce code JavaScript que vous pourrez afficher une notification.

Voyons en détail ce que chacune de ces étapes implique.

Étape 1 : Côté client

La première étape consiste à "abonner" un utilisateur aux messages push.

Pour abonner un utilisateur, vous devez respecter deux conditions. Tout d'abord, obtenez l'autorisation de l'utilisateur pour lui envoyer des messages push. Deuxièmement, obtenir un PushSubscription à partir du navigateur.

Un PushSubscription contient toutes les informations dont nous avons besoin pour envoyer un message push à cet utilisateur. Vous pouvez considérer cela comme un identifiant de l'appareil de cet utilisateur.

Tout cela se fait en JavaScript avec l'API Push.

Navigateurs pris en charge

Source

Avant d'abonner un utilisateur, vous devez générer un ensemble de "clés de serveur d'application" dont nous parlerons plus tard.

Les clés du serveur d'application, également appelées clés VAPID, sont propres à votre serveur. Ils permettent à un service de transfert de données par poussée de savoir quel serveur d'application a souscrit un utilisateur et de s'assurer qu'il s'agit du même serveur qui déclenche les messages de transfert de données par poussée vers cet utilisateur.

Une fois que vous avez souscrit l'abonnement de l'utilisateur et que vous disposez d'un PushSubscription, vous devez envoyer les informations PushSubscription à votre backend/serveur. Sur votre serveur, vous enregistrerez cet abonnement dans une base de données et l'utiliserez pour envoyer un message push à cet utilisateur.

Assurez-vous d'envoyer le PushSubscription à votre backend.

Étape 2 : Envoyer un message push

Lorsque vous souhaitez envoyer un message push à vos utilisateurs, vous devez effectuer un appel d'API à un service push. Cet appel d'API inclut les données à envoyer, à qui envoyer le message et les critères d'envoi du message. Normalement, cet appel d'API est effectué à partir de votre serveur.

Voici quelques questions que vous pourriez vous poser :

Qui est le service push et en quoi consiste-t-il ?
À quoi ressemble l'API ? S'agit-il de JSON, de XML ou d'un autre format ?
À quoi sert l'API ?

Qui est le service push et en quoi consiste-t-il ?

Un service push reçoit une requête réseau, la valide et envoie un message push au navigateur approprié. Si le navigateur est hors connexion, le message est mis en file d'attente jusqu'à ce que le navigateur se connecte.

Chaque navigateur peut utiliser n'importe quel service push, ce qui n'est pas sous le contrôle des développeurs. Ce n'est pas un problème, car chaque service de transfert par poussée attend le même appel d'API. Cela signifie que vous n'avez pas à vous soucier de l'identité du service de transfert. Vous devez simplement vous assurer que votre appel d'API est valide.

Pour obtenir l'URL appropriée pour déclencher un message push (c'est-à-dire l'URL du service push), il vous suffit de consulter la valeur endpoint dans un PushSubscription.

Vous trouverez ci-dessous un exemple des valeurs fournies par un abonnement PushSubscription:

{
  "endpoint": "https://random-push-service.com/some-kind-of-unique-id-1234/v2/",
  "keys": {
    "p256dh": "BNcRdreALRFXTkOOUHK1EtK2wtaz5Ry4YfYCA_0QTpQtUbVlUls0VJXg7A8u-Ts1XbjhazAkj7I99e8QcYP7DkM=",
    "auth": "tBHItJI5svbpez7KI4CCXg=="
  }
}

Le point de terminaison dans ce cas est [https://random-push-service.com/some-kind-of-unique-id-1234/v2/]. Le service de transfert de données par poussée serait "random-push-service.com", et chaque point de terminaison est propre à un utilisateur, indiqué par "un-certain-type-d-identifiant-unique-1234". Lorsque vous commencerez à travailler avec la poussée, vous remarquerez ce schéma.

Les clés de l'abonnement seront abordées plus tard.

À quoi ressemble l'API ?

Comme je l'ai dit, chaque service Web push attend le même appel d'API. Cette API est le protocole Web Push. Il s'agit d'une norme IETF qui définit comment effectuer un appel d'API à un service push.

L'appel d'API nécessite que certains en-têtes soient définis et que les données soient un flux d'octets. Nous allons examiner les bibliothèques pouvant effectuer cet appel d'API à notre place, ainsi que la procédure à suivre pour le faire nous-mêmes.

À quoi sert l'API ?

L'API permet d'envoyer un message à un utilisateur, avec ou sans données, et fournit des instructions sur la manière d'envoyer le message.

Les données que vous envoyez avec un message push doivent être chiffrées. En effet, cela empêche les services push, même n'importe qui, de consulter les données envoyées avec le message push. Cela est important, car c'est le navigateur qui décide du service de push à utiliser, ce qui pourrait ouvrir la porte aux navigateurs qui utilisent un service de push non sécurisé.

Lorsque vous déclenchez un message push, le service push reçoit l'appel d'API et met le message en file d'attente. Ce message restera en file d'attente jusqu'à ce que l'appareil de l'utilisateur soit en ligne et que le service de push puisse distribuer les messages. Les instructions que vous pouvez donner au service de push définissent la mise en file d'attente du message push.

Les instructions incluent des informations telles que :

Durée de vie d'un message push. Ce paramètre définit la durée pendant laquelle un message doit être mis en file d'attente avant d'être supprimé et non distribué.
Définissez le degré d'urgence du message. Cela est utile si le service push préserve l'autonomie de la batterie des utilisateurs en ne transmettant que des messages à priorité élevée.
Attribuez un nom de "sujet" à un message push. Ce nouveau message remplacera tous les messages en attente.

Lorsque votre serveur souhaite envoyer un message push, il envoie une requête de protocole Web Push à un service push.

Étape 3: Événement push sur l'appareil de l'utilisateur

Une fois que nous avons envoyé un message push, le service de push conserve votre message sur son serveur jusqu'à ce qu'un des événements suivants se produise :

L'appareil se connecte et le service de messages push envoie le message.
Le message expire. Dans ce cas, le service push supprime le message de sa file d'attente et il ne sera jamais distribué.

Lorsque le service push envoie un message, le navigateur le reçoit, déchiffre les données et envoie un événement push à votre service worker.

Un service worker est un fichier JavaScript "spécial". Le navigateur peut exécuter ce code JavaScript sans que votre page soit ouverte. Il peut même exécuter ce code JavaScript lorsque le navigateur est fermé. Un service worker dispose également d'API, comme le push, qui ne sont pas disponibles sur la page Web (c'est-à-dire des API qui ne sont pas disponibles en dehors d'un script de service worker).

C'est dans l'événement "push" du service worker que vous pouvez effectuer des tâches en arrière-plan. Vous pouvez effectuer des appels d'analyse, mettre des pages en cache hors connexion et afficher des notifications.

Lorsqu'un message push est envoyé par un service push à l'appareil d'un utilisateur, votre service worker reçoit un événement push.

C'est l'ensemble du flux de la messagerie push.