Fonctionnement du transfert

Avant de nous intéresser à l'API, examinons les 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 comment et pourquoi elles sont importantes.

Les trois étapes clés de l'implémentation des notifications push sont les suivantes :

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 notifications push).
2. L'appel d'API depuis votre backend / application qui déclenche l'envoi d'une notification push à l'appareil d'un utilisateur.
3. Le fichier JavaScript du service worker qui recevra un "événement push" lorsque la notification arrivera sur l'appareil. C'est dans ce code JavaScript que vous pourrez afficher une notification.

Examinons chacune de ces étapes plus en détail.

Étape 1 : Côté client

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

Pour abonner un utilisateur, deux éléments sont nécessaires. Tout d'abord, obtenir son autorisation pour lui envoyer des notifications push. Ensuite, obtenir un PushSubscription du navigateur.

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

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

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

Les clés de serveur d'application, également appelées clés VAPID, sont uniques à votre serveur. Elles permettent à un service push de savoir quel serveur d'application a abonné un utilisateur et de s'assurer qu'il s'agit du même serveur qui déclenche les notifications push pour cet utilisateur.

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

Étape 2 : Envoyer une notification push

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

Voici quelques questions que vous pourriez vous poser :

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

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

Un service push reçoit une requête réseau, la valide et envoie une notification push au navigateur approprié. Si le navigateur est hors connexion, le message est mis en file d'attente jusqu'à ce qu'il soit de nouveau en ligne.

Chaque navigateur peut utiliser le service push de son choix. Les développeurs n'ont aucun contrôle sur ce point. Ce n'est pas un 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. Vous devez simplement vous assurer que votre appel d'API est valide.

Pour obtenir l'URL appropriée afin de déclencher une notification 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 que vous obtiendrez à partir 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 est "random-push-service.com" et chaque point de terminaison est unique à un utilisateur, indiqué par "some-kind-of-unique-id-1234". Lorsque vous commencerez à utiliser les notifications push, vous remarquerez ce modèle.

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

À quoi ressemble l'API ?

J'ai mentionné que chaque service push Web 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 la définition de certains en-têtes et la transmission des données sous forme de flux d'octets. Nous examinerons 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 manière d'envoyer le message.

Les données que vous envoyez avec une notification push doivent être chiffrées. En effet, cela empêche les services push, qui peuvent être n'importe qui, de pouvoir afficher les données envoyées avec la notification push. Ceci est important, car c'est le navigateur qui décide du service push à utiliser, ce qui pourrait ouvrir la voie à des navigateurs utilisant un service push qui n'est pas sûr ou sécurisé.

Lorsque vous déclenchez une notification 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 push puisse envoyer les messages. Les instructions que vous pouvez donner au service push définissent la manière dont la notification push est mise en file d'attente.

Les instructions incluent des détails tels que :

• La durée de vie d'une notification push. Elle définit la durée pendant laquelle un message doit être mis en file d'attente avant d'être supprimé et non envoyé.

• Définir l'urgence du message. Cela est utile si le service push préserve l'autonomie de la batterie des utilisateurs en n'envoyant que les messages prioritaires.

• Attribuer un nom de "sujet" à une notification 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é une notification push, le service push conserve votre message sur son serveur jusqu'à ce que l'un des événements suivants se produise :

1. L'appareil se connecte et le service push envoie 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 envoyé.

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

Un service worker est un "special" fichier JavaScript. Le navigateur peut exécuter ce code JavaScript sans que votre page soit ouverte. Il peut même l'exécuter lorsque le navigateur est fermé. Un service worker dispose également d'API, comme les notifications push, qui ne sont pas disponibles sur la page Web (c'est-à-dire les 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.

Voilà tout le flux des notifications push.

Étapes suivantes

• Présentation des notifications push Web
• Fonctionnement des notifications push
• Abonner un utilisateur
• Expérience utilisateur pour l'autorisation
• Envoyer des messages avec des 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 notifications push
• Créer un serveur de notifications push