Fonctionnement du transfert

Matt Gaunt

Avant d'entrer dans les détails de l'API, examinons le fonctionnement des notifications push de manière générale, du début à la fin. Ensuite, lorsque nous aborderons des sujets ou des API spécifiques, vous comprendrez mieux comment et pourquoi ils sont importants.

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

1. Ajouter la logique côté client pour abonner un utilisateur aux notifications push (c'est-à-dire le code JavaScript et l'interface utilisateur de votre application Web qui enregistrent un utilisateur pour les messages push).
2. Appel d'API depuis votre backend/application qui déclenche un message push sur l'appareil d'un utilisateur.
3. Le 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.

Examinons plus 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, deux éléments sont nécessaires. Tout d'abord, obtenir 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 pour l'appareil de cet utilisateur.

Tout cela est effectué en JavaScript avec l'API Push.

Browser Support

• 42
• 17
• 44
• 16

Source

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

Les clés du serveur d'application, également appelées clés VAPID, sont propres à votre serveur. Elles permettent à un service push de savoir quel serveur d'application a abonné un utilisateur et de s'assurer que c'est le même serveur qui déclenche les messages push destinés à cet utilisateur.

Une fois que vous avez abonné l'utilisateur et que vous disposez d'un PushSubscription, vous devez envoyer les détails du 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.

Étape 2 : Envoyer un message push

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

Voici quelques questions que vous pourriez vous poser :

• Qui et qu'est-ce que le service push ?
• À quoi ressemble l'API ? Est-ce du JSON, du XML ou autre chose ?
• Que peut faire l'API ?

Qui et qu'est-ce que le service push ?

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 qu'il se reconnecte.

Chaque navigateur peut utiliser le service push de son choix. Les développeurs n'ont aucun contrôle sur ce point. Cela ne pose pas de problème, car chaque service push attend le même appel d'API. Cela signifie que vous n'avez pas à vous soucier de l'identité du service push. Il vous suffit de 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 regarder la valeur endpoint dans un PushSubscription.

Voici un exemple des valeurs que vous obtiendrez d'un PushSubscription :

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

Dans ce cas, le point de terminaison est https://random-push-service.com/some-kind-of-unique-id-1234/v2/. Le service push serait "random-push-service.com" et chaque point de terminaison est unique pour un utilisateur, indiqué par "some-kind-of-unique-id-1234". Lorsque vous commencerez à utiliser les notifications push, vous remarquerez ce schéma.

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

À quoi ressemble l'API ?

J'ai mentionné que 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 vers un service push.

L'appel d'API nécessite la définition de certains en-têtes et que les données soient un flux d'octets. Nous allons examiner les bibliothèques qui peuvent effectuer cet appel d'API pour nous, ainsi que la manière de le faire nous-mêmes.

Que peut faire l'API ?

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

Les données que vous envoyez avec un message push doivent être chiffrées. Cela empêche les services push, qui peuvent être n'importe qui, de voir les données envoyées avec le message push. C'est important, car c'est le navigateur qui décide du service push à utiliser, ce qui pourrait ouvrir la porte à des navigateurs utilisant un service push qui n'est pas sûr ou 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 se connecte et que le service push puisse distribuer les messages. Les instructions que vous pouvez donner au service push définissent la manière dont le message push est mis en file d'attente.

Les instructions incluent des détails tels 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 de ne pas être distribué.

• Définissez le niveau d'urgence du message. Cela est utile si le service push préserve l'autonomie de la batterie des utilisateurs en ne diffusant que les messages à priorité élevée.

• Attribuez un nom de "sujet" à un message push, qui remplacera tout message en attente par ce nouveau message.

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

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

1. L'appareil se connecte et le service push transmet le message.
2. 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 transmet un message, le navigateur le reçoit, déchiffre les données et distribue un événement push dans 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, telles que les notifications 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 en cache des pages hors connexion et afficher des notifications.

C'est tout pour le flux de messagerie push.

Étapes suivantes

• Présentation des notifications push Web
• Fonctionnement du push
• Abonner un utilisateur
• Expérience utilisateur liée aux autorisations
• Envoyer des messages avec les bibliothèques Web Push
• Protocole Web Push
• Gérer les événements push
• Afficher une notification
• Comportement des notifications
• Modèles de notification courants
• Questions fréquentes sur les notifications push
• Problèmes courants et signalement de bugs

Ateliers de programmation

• Créer un client de notification push
• Créer un serveur de notifications push