Abonnements Push

Ce document fournit une présentation d'un abonnement push, de son workflow et des propriétés associées.

Dans le cas d'une distribution push, Pub/Sub lance des requêtes à l'application d'abonnés pour distribuer des messages. Les messages sont distribués à un serveur adressable publiquement ou à un webhook, comme une requête HTTPS POST.

Les abonnements push minimisent les dépendances vis-à-vis des bibliothèques clientes et des mécanismes d'authentification spécifiques à Pub/Sub. Ils fonctionnent également bien avec les technologies de service sans serveur et à autoscaling, telles que les fonctions Cloud Run, Cloud Run et Google Kubernetes Engine.

Avant de commencer

Avant de lire ce document, assurez-vous de bien comprendre les points suivants :

• Le fonctionnement de Pub/Sub et les différents termes associés.

• Les différents types d'abonnements compatibles avec Pub/Sub et les raisons pour lesquelles vous pouvez utiliser un abonnement push.

Workflow d'un abonnement push

Dans un abonnement push, un serveur Pub/Sub lance une requête à votre client abonné pour distribuer des messages.

L'image suivante illustre le workflow entre un client abonné et un abonnement push.

Voici une brève description du workflow qui fait référence à la figure 3 :

1. Le serveur Pub/Sub envoie chaque message en tant que requête HTTPS destinée au client abonné, à un point de terminaison préconfiguré. Cette requête est représentée par PushRequest dans l'image.
2. Le point de terminaison accuse réception du message en renvoyant un code d'état HTTP de réussite. Une réponse négative indique que Pub/Sub doit renvoyer les messages. Cette réponse est représentée par PushResponse dans l'image.
3. Pub/Sub ajuste de manière dynamique la fréquence des requêtes push en fonction du taux de réception de réponses de réussite.

Propriétés d'un abonnement push

Les propriétés que vous configurez pour un abonnement push déterminent comment vous écrivez des messages dans votre abonnement. Pour en savoir plus, consultez la section Propriétés d'abonnement.

Comment les points de terminaison push reçoivent-ils des messages ?

Lorsque Pub/Sub transmet un message à un point de terminaison push, vous pouvez choisir de l'envoyer encapsulé ou non encapsulé. Par défaut, les messages sont envoyés encapsulés.

• Encapsulé Pub/Sub envoie le message dans le corps JSON d'une requête POST.
• Non encapsulé Pub/Sub envoie directement les données brutes du message en tant que corps HTTP.

Les exemples suivants montrent un corps encapsulé d'une requête POST JSON vers un point de terminaison push contenant la chaîne Hello there dans le champ message.data.

Le corps d'une requête POST est un objet JSON. Les données du message se trouvent dans le champ message.data et sont encodées en base64.

Exemple de requête avec les valeurs minimales

  {
      "message": {
          "data": "SGVsbG8gQ2xvdWQgUHViL1N1YiEgSGVyZSBpcyBteSBtZXNzYWdlIQ==",
          "messageId": "2070443601311540",
          "message_id": "2070443601311540",
          "publishTime": "2021-02-26T19:13:55.749Z",
          "publish_time": "2021-02-26T19:13:55.749Z"
      },
    "subscription": "projects/myproject/subscriptions/mysubscription"
  }
  

Exemple de requête avec les valeurs maximales

Notez que cet exemple montre les valeurs maximales actuelles, qui peuvent changer au fil du temps. De plus, la carte d'attributs peut contenir une variété de valeurs.

  {
      "deliveryAttempt": 5,
      "message": {
          "attributes": {
              "key": "value"
          },
          "data": "SGVsbG8gQ2xvdWQgUHViL1N1YiEgSGVyZSBpcyBteSBtZXNzYWdlIQ==",
          "messageId": "2070443601311540",
          "message_id": "2070443601311540",
          "orderingKey": "key",
          "publishTime": "2021-02-26T19:13:55.749Z",
          "publish_time": "2021-02-26T19:13:55.749Z"