RCS Business Messaging est maintenant dans l'API Messages de Vonage

A noter : Ce billet annonce la version bêta de RCS Business Messaging dans l'API Messages de Vonage. RCS Messaging est maintenant disponible en général (GA) dans l'API Messages de Vonage. Pour en savoir plus, consultez notre annonce de sortie.

L'API Vonage Messages API prend désormais en charge la messagerie RCS Business (en version bêta). Si vous ne connaissez pas encore l'API Messages, il s'agit d'une API REST pour la messagerie omnicanale. Elle fournit une interface standardisée et facile à utiliser pour envoyer et recevoir des messages via SMS, MMS, WhatsApp, Facebook Messenger, Viber, et maintenant RCS !

Si vous n'avez jamais entendu parler du RCS, vous vous demandez peut-être ce qu'est exactement la messagerie RCS.

Qu'est-ce que la messagerie RCS ?

RCS, ou Rich Communication Services, est un protocole de communication permettant d'envoyer des messages à des appareils connectés à un réseau de téléphonie cellulaire et entre ces appareils. Outre du texte, les messages RCS peuvent contenir des photos, des vidéos, des fichiers, etc.

Vous vous dites peut-être que cela ressemble beaucoup à la messagerie MMS. En fait, c'est un peu le cas, mais il y a d'importantes différences :

• Les messages MMS peuvent être envoyés via le réseau cellulaire, tandis que les messages RCS nécessitent une connexion à l'internet (soit via une connexion de données cellulaires, soit via le Wi-Fi).

• Les messages RCS autorisent également des tailles de fichiers plus importantes que les MMS pour les images, les vidéos et les fichiers.

• Les messages RCS permettent une plus grande interactivité que les MMS, avec des types de messages avancés permettant d'afficher des médias et des boutons de rendu pour les réponses suggérées afin d'effectuer des actions spécifiques telles que la composition d'un numéro ou l'ouverture d'un lieu dans une application de cartographie.

À bien des égards, les fonctionnalités de la messagerie RCS se rapprochent de celles de la messagerie OTT (Over-The-Top) que vous connaissez peut-être via des applications telles que WhatsApp, Facebook Messenger, Viber et d'autres. L'avantage du RCS par rapport à ces autres canaux est que la messagerie RCS est prise en charge nativement dans l'application de messagerie intégrée d'un téléphone, plutôt que les utilisateurs aient à installer une application tierce sur leurs appareils.

Cet avantage s'accompagne toutefois d'un inconvénient majeur : la prise en charge des appareils.

Prise en charge des appareils

La messagerie RCS n'est actuellement prise en charge que sur les appareils Android. Dans un récent communiqué de presseApple a toutefois déclaré que la messagerie RCS serait prise en charge dans le cadre de la prochaine version d'iOS 18 :

Lorsque vous envoyez des messages à des contacts qui n'ont pas d'appareil Apple, l'app Messages prend désormais en charge RCS pour des médias plus riches et des messages de groupe plus fiables que les SMS et les MMS.

Les détails exacts de la prise en charge de RCS par Apple ne sont pas connus à ce stade, et il n'est pas clair si la prise en charge inclura la messagerie professionnelle RCS ou si elle concernera uniquement la messagerie d'égal à égal.

Types de messages

Approfondissons la mise en œuvre de RCS par Vonage dans l'API Messages en examinant les différents types de messages qui peuvent être envoyés et reçus.

Le canal RCS de l'API Messages de Vonage exploite les serveurs RBM (RCS Business Messaging) de Google et prend en charge les différents types de messages disponibles via Google RBM. Le canal prend en charge la messagerie sortante (messages envoyés par l'entreprise au client) et la messagerie entrante (messages envoyés par le client à l'entreprise, en réponse à un message sortant). Dans ces deux catégories, il existe de nombreux types de messages différents. Nous les énumérerons brièvement ici avant d'examiner quelques exemples spécifiques de certains d'entre eux.

Pour les messages sortants, certains types de messages Google RBM sont abstraits en types spécifiques que vous connaissez peut-être déjà grâce à d'autres canaux de l'API Messages, tels que text, image, videoet file. Il existe également un type de message custom qui prend en charge les messages RBM plus complexes tels que les réponses suggérées, les actions suggérées, les cartes enrichies et les carrousels.

Les messages entrants sont reçus par l'intermédiaire d'un crochet Web configuré dans votre tableau de bord du développeur Vonage. Pour RCS, il existe plusieurs types de messages entrants. Le type reçu par le webhook dépend soit du contenu du message envoyé par le client, soit de la façon dont le client interagit avec un message envoyé par l'entreprise. L'envoi par le client d'un texte, d'un média ou d'un lieu entraînera la réception de messages de type text, image, video, audio, vcard, fileou location. Le client qui interagit avec un message de réponse suggérée ou d'action suggérée recevra des messages entrants de type reply ou button.

Enfin, comme pour tous les canaux de l'API Messages, les messages RCS sortants reçoivent des mises à jour de l'état du message via un webhook (une fois de plus configuré dans le tableau de bord du développeur Vonage). Pour les messages RCS, ces mises à jour de statut comprennent un read pour indiquer que le destinataire du message l'a lu.

Il peut être plus facile de visualiser certains de ces types de messages en examinant quelques exemples de code, alors faisons-le maintenant !

Exemples de codes

Messages sortants

Examinons d'abord quelques messages sortants, en commençant par un message de base text de base.

Comme pour tous les canaux de l'API Messages, l'envoi d'un message RCS nécessite de faire une demande au point de terminaison de l'API Messages de Vonage avec la charge utile JSON appropriée. POST au point de terminaison de l'API Messages de Vonage avec la charge utile JSON appropriée. Certaines propriétés de l'objet JSON, telles que channel, message_type, to, et from sont communes à tous les canaux et types de messages, tandis que d'autres sont spécifiques au canal et/ou au type de message. Pour un message texte RCS sortant, le JSON serait structuré comme suit :

{
  "to": "447900000000",
  "from": "Vonage",
  "channel": "rcs",
  "message_type": "text",
  "text": "Hello world!"
}

Cela se traduirait comme suit dans l'application de messagerie des destinataires :

Screenshot of an RCS text message

Le JSON pour image, video, et file est similaire, sauf qu'ils doivent inclure un objet avec une propriété url dont la valeur est une URL accessible au public pour le fichier que vous souhaitez envoyer. Par exemple, le JSON pour envoyer la photo d'un chat pourrait ressembler à ceci :

{
  "to": "447900000000",
  "from": "Vonage",
  "channel": "rcs",
  "message_type": "image",
  "image": {
    "url": "https://example.com/cat.jpg"
  }
}

et entraîner l'affichage du message suivant dans l'appli de messagerie du destinataire :

Screenshot of an RCS image message

Tous les autres messages RCS sortants sont pris en charge par le type de message custom sont pris en charge par le type de message Ces messages comprennent un objet custom contenant les propriétés relatives au message spécifique. Il y a trop de sous-types et de permutations à couvrir dans cet article, mais un exemple pourrait être un message avec deux boutons de réponse suggérés :

{
  "to": "447900000000",
  "from": "Vonage",
  "channel": "rcs",
  "message_type": "custom",
  "custom": {
    "contentMessage": {
      "text": "What do you think of Vonage APIs?",
      "suggestions": [
        {
          "reply": {
            "text": "They're great!",
            "postbackData": "suggestion_1"
          }
        },
        {
          "reply": {
            "text": "They're awesome!",
            "postbackData": "suggestion_2"
          }
        }
      ]
    }
  }
}

qui affichera ce qui suit :

Un autre exemple pourrait être un message suggérant d'ouvrir un URL :

{
  "to": "447900000000",
  "from": "Vonage",
  "channel": "rcs",
  "message_type": "custom",
  "custom": {
    "contentMessage": {
      "text": "Check out our latest offers!",
      "suggestions": [
        {
          "action": {
            "text": "Open product page",
            "postbackData": "postback_data_1234",
            "openUrlAction": {
              "url": "http://example.com/"
            }
          }
        }
      ]
    }
  }
}

ce qui donnerait le résultat suivant :

Screenshot of an RCS suggested action message

Bien que la structure de ces deux types de messages soit différente, vous avez peut-être remarqué que les symboles reply et action contiennent tous deux une propriété postbackData . La valeur de cette propriété devient pertinente dans le contexte du message entrant qui est déclenché lorsque le destinataire interagit avec le message de réponse suggérée ou d'action suggérée. Nous allons maintenant nous pencher sur les messages entrants.

Messages entrants

Comme indiqué précédemment, les messages entrants sont reçus via un webhook. Il existe différents types de messages entrants, et nous ne les aborderons pas tous ici, mais nous pouvons en donner quelques exemples.

Comme pour les messages sortants, certains champs de la charge utile JSON sont communs à tous les canaux et à tous les types de messages. Les champs to, from, channel, et message_type que vous avez déjà vus dans les exemples de messages sortants ci-dessus. En outre, les messages entrants contiennent d'autres champs standard ; message_uuid qui est un identifiant unique pour le message, et timestamp qui indique la date et l'heure auxquelles le message entrant a été délivré. Au-delà de ces propriétés standard, le contenu de la charge utile du webhook dépend du type de message.

Types tels que text, image, video, audio, vcard, fileet location contiendront des données basées sur le message envoyé par l'appareil du client. Pour les types de messages qui impliquent l'envoi d'un média ou d'un fichier, la charge utile comprendra un lien vers le fichier sur les serveurs multimédias de Vonage. Par exemple, la charge utile du webhook pour un message d'image peut ressembler à ceci :

{
  "to": "Vonage",
  "from": "447900000000",
  "channel": "rcs",
  "message_uuid": "aaaaaaaa-bbbb-cccc-dddd-0123456789ab",
  "timestamp": "2024-02-08T10:12:44Z",
  "context_status": "none",
  "message_type": "image",
  "image": {
    "name": "image.jpg",
    "url": "https://api-eu.nexmo.com/v3/media/6882bbe2-fe14-4e2f-910f-652bbbb058d4"
  }
}

L'entrée reply et les messages entrants button sont envoyés à la suite de l'interaction des clients avec les messages de réponse suggérée et d'action suggérée respectivement. Plus tôt dans cet article, nous avons mentionné la propriété postbackData dans ces types de messages sortants, et c'est ici que la valeur définie pour cette propriété entre en jeu.

Si l'on reprend l'exemple de la réponse suggérée, si le client a sélectionné le bouton qui lit They're awesome! le message entrant reply ressemblerait à ceci, avec la valeur de postbackData contenue dans la propriété id de l'objet reply de l'objet :

{
  "to": "Vonage",
  "from": "447900000000",
  "channel": "rcs",
  "message_uuid": "aaaaaaaa-bbbb-cccc-dddd-0123456789ab",
  "timestamp": "2024-02-08T10:12:44Z",
  "context_status": "none",
  "message_type": "reply",
  "reply": {
    "id": "suggestion_2",
    "title": "They're awesome!"
  }
}

Un message entrant button contient également la valeur de postbackDatamais cette fois-ci, elle est définie comme la propriété payload de l'objet button objet. A button déclenché par un client qui ouvre l'URL du message d'action suggéré plus haut ressemblerait à ceci :

{
  "to": "Vonage",
  "from": "447900000000",
  "channel": "rcs",
  "message_uuid": "aaaaaaaa-bbbb-cccc-dddd-0123456789ab",
  "timestamp": "2024-02-08T10:12:44Z",
  "context_status": "none",
  "message_type": "button",
  "button": {
    "payload": "postback_data_1234",
    "text": "Open product page"
  }
}

Dans ces deux cas, la valeur de ce postbackData peut être utilisée pour identifier l'action entreprise par le client. Une logique peut alors être construite autour de cette action pour déclencher d'autres messages sortants dans le cadre d'un flux de messages global.

Synthèse

Dans cet article, nous avons étudié des exemples d'envoi et de réception de messages individuels de différents types. La puissance potentielle de RCS, comparée aux canaux tels que les SMS et les MMS, réside dans la combinaison de ces différents types de messages pour construire des flux de messagerie riches et interactifs qui peuvent être utilisés pour de nombreux cas d'utilisation transactionnels ou marketing différents.

RCS offre la possibilité d'une expérience de messagerie engageante, similaire à celle offerte par les applications de messagerie telles que WhatsApp, Facebook Messenger, et Viber. La prise en charge native du RCS sur les appareils des clients signifie qu'ils n'ont pas besoin de télécharger une application spécifique pour recevoir ces messages, ce qui élargit considérablement la portée potentielle de la messagerie RCS par rapport aux canaux spécifiques des applications de messagerie. La pierre d'achoppement de cette portée a toujours été le manque de support des appareils par Apple, mais avec RCS qui devrait être supporté dans iOS 18, c'est le moment idéal pour commencer à utiliser RCS et à l'intégrer dans votre système de messagerie.

Si vous êtes enthousiasmé par RCS et que vous voulez en savoir plus, vous pouvez vous plonger directement dans notre documentation pour les développeurs. Pendant que vous y êtes, vous pouvez consulter tous les autres canaux offerts par l'API Messages ou explorer nos nombreuses autres API de communication.

Nous aimerions également que vous vous joigniez à nous sur le Slack des développeurs de Vonage ou envoyez-nous un message sur Xet nous vous répondrons !