https://a.storyblok.com/f/270183/1368x665/536a2cfe5b/rcs-business-messaging.png

RCS Business Messaging ist jetzt Bestandteil der Vonage Messages API

Zuletzt aktualisiert am July 2, 2024

Lesedauer: 7 Minuten

Bitte beachten: Dieser Beitrag kündigt die Beta-Version von RCS Business Messaging in der Vonage Messages API an. RCS Messaging ist jetzt allgemein verfügbar (GA) in der Vonage Messages API. Mehr darüber erfahren Sie in unserer Ankündigung.

Die Vonage Messages API unterstützt jetzt RCS Business Messaging (in Beta). Falls Sie mit der Messages API noch nicht vertraut sind, handelt es sich um eine REST-API für Omnichannel-Messaging. Sie bietet eine standardisierte und einfach zu bedienende Schnittstelle zum Senden und Empfangen von Nachrichten über SMS, MMS, WhatsApp, Facebook Messenger, Viber und jetzt auch RCS!

Wenn Sie noch nie von RCS gehört haben, fragen Sie sich vielleicht: "Was genau ist RCS Messaging?" Finden wir es heraus!

Was ist RCS Messaging?

RCS (Rich Communication Services) ist ein Kommunikationsprotokoll zum Senden von Nachrichten an und zwischen Geräten, die mit einem Mobilfunknetz verbunden sind. RCS-Nachrichten können nicht nur Text, sondern auch Fotos, Videos, Dateien und mehr enthalten.

Sie werden vielleicht denken, dass das sehr nach MMS-Nachrichten klingt. Nun, irgendwie schon, aber es gibt einige wichtige Unterschiede:

  • MMS-Nachrichten können über das Mobilfunknetz zugestellt werden, während RCS-Nachrichten eine Verbindung zum Internet erfordern (entweder über eine mobile Datenverbindung oder Wi-Fi).

  • RCS-Nachrichten erlauben auch größere Dateigrößen für Bilder, Videos und Dateien als MMS.

  • RCS-Nachrichten ermöglichen mehr Interaktivität als MMS, mit erweiterten Nachrichtentypen für die Anzeige von Medien und die Darstellung von Schaltflächen für vorgeschlagene Antworten zur Durchführung bestimmter Aktionen wie das Wählen einer Nummer oder das Öffnen eines Standorts in einer Karten-App.

In vielerlei Hinsicht ähnelt RCS Messaging in seiner Funktionalität dem OTT (Over-The-Top) Messaging, mit dem Sie vielleicht über Apps wie WhatsApp, Facebook Messenger, Viber und andere vertraut sind. Der Vorteil von RCS gegenüber diesen anderen Kanälen besteht darin, dass RCS-Messaging nativ in der integrierten Messaging-App eines Telefons unterstützt wird und die Nutzer nicht eine Drittanbieter-App auf ihren Geräten installieren müssen.

Dieser Vorteil ist jedoch mit einem großen Nachteil verbunden: der Geräteunterstützung.

Geräteunterstützung

RCS-Messaging wird derzeit nur auf Android-Geräten unterstützt. In einer jüngsten Pressemitteilungerklärte Apple jedoch, dass RCS in der kommenden Version von iOS 18 unterstützt werden wird:

Beim Versenden von Nachrichten an Kontakte, die kein Apple-Gerät besitzen, unterstützt die Nachrichten-App jetzt RCS für reichhaltigere Medien und zuverlässigeres Gruppen-Messaging im Vergleich zu SMS und MMS.

Die genauen Details der Apple-Unterstützung für RCS sind zu diesem Zeitpunkt noch nicht bekannt, und es ist nicht klar, ob die Unterstützung RCS Business Messaging einschließt oder nur für Peer-to-Peer-Messaging gilt.

Nachrichtentypen

Schauen wir uns die Vonage-Implementierung von RCS in der Messages API etwas genauer an, indem wir uns die verschiedenen Nachrichtentypen ansehen, die gesendet und empfangen werden können.

Der RCS-Kanal der Vonage Messages API nutzt die RBM-Server (RCS Business Messaging) von Google und unterstützt die verschiedenen über Google RBM verfügbaren Nachrichtentypen. Der Kanal unterstützt sowohl Outbound Messaging (vom Unternehmen an den Kunden gesendete Nachrichten) als auch Inbound Messaging (vom Kunden an das Unternehmen gesendete Nachrichten als Antwort auf eine Outbound-Nachricht). Innerhalb dieser beiden Kategorien gibt es viele verschiedene Arten von Nachrichten. Wir werden sie hier kurz auflisten, bevor wir uns einige spezifische Beispiele für einige Typen ansehen.

Für ausgehende Nachrichten werden einige der Google RBM-Nachrichtentypen zu spezifischen Typen abstrahiert, die Sie vielleicht schon von anderen Messages API-Kanälen kennen, wie z. B. text, image, videound file. Außerdem gibt es einen custom Nachrichtentyp, der die komplexeren RBM-Nachrichten wie Antwortvorschläge, Aktionsvorschläge, Rich Cards und Karussells unterstützt.

Eingehende Nachrichten werden über einen Webhook empfangen, der in Ihrem Vonage Entwickler Dashboard. Für RCS gibt es mehrere Typen eingehender Nachrichten. Welcher Typ vom Webhook empfangen wird, hängt entweder vom Inhalt der vom Kunden gesendeten Nachricht ab oder davon, wie der Kunde mit einer vom Unternehmen gesendeten Nachricht interagiert. Wenn der Kunde Text, eine Art von Medien oder einen Standort sendet, werden eingehende Nachrichten des Typs text, image, video, audio, vcard, file, oder location. Wenn der Kunde mit einer vorgeschlagenen Antwort oder einer vorgeschlagenen Aktion interagiert, führt dies zu eingehenden Nachrichten des Typs reply oder button.

Schließlich erhalten ausgehende RCS-Nachrichten wie alle Messages API-Kanäle Nachrichtenstatusaktualisierungen über einen Webhook (ebenfalls im Vonage Developer Dashboard eingerichtet). Für RCS-Nachrichten enthalten diese Statusaktualisierungen einen read Status, der angibt, wann der Empfänger der Nachricht die Nachricht gelesen hat.

Einige dieser Nachrichtentypen lassen sich vielleicht leichter veranschaulichen, wenn man sich ein paar Code-Beispiele ansieht, also lassen Sie uns das jetzt tun!

Code-Beispiele

Ausgehende Nachrichten

Schauen wir uns zunächst einige ausgehende Nachrichten an, beginnend mit einer einfachen text Nachricht.

Wie bei allen Messages API-Kanälen ist für das Senden einer RCS-Nachricht eine POST Anfrage an den Vonage Messages API-Endpunkt mit der entsprechenden JSON-Nutzlast. Einige der JSON-Objekteigenschaften, wie z. B. channel, message_type, to, und from sind für alle Kanäle und Nachrichtentypen gleich, und einige sind spezifisch für den jeweiligen Kanal und/oder Nachrichtentyp. Bei einer ausgehenden RCS-Textnachricht wäre das JSON-Objekt wie folgt strukturiert:

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

Dies würde in der Nachrichten-App des Empfängers wie folgt angezeigt:

Screenshot of an RCS text messageScreenshot of an RCS text message

Das JSON für image, video, und file Nachrichten ist ähnlich, außer dass sie ein Objekt mit einer url Eigenschaft enthalten, deren Wert eine öffentlich zugängliche URL für die Datei ist, die Sie senden möchten. Das JSON zum Senden eines Katzenbildes könnte zum Beispiel so aussehen:

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

und führen dazu, dass in der Messaging-App des Empfängers die folgende Nachricht angezeigt wird:

Screenshot of an RCS image messageScreenshot of an RCS image message

Alle anderen ausgehenden RCS-Nachrichten werden vom custom Nachrichtentyp unterstützt. Diese Nachrichten enthalten ein custom Objekt, das die für die jeweilige Nachricht relevanten Eigenschaften enthält. Es gibt zu viele Untertypen und Permutationen, um sie in diesem Artikel zu behandeln, aber ein Beispiel könnte eine Nachricht mit zwei vorgeschlagenen Antwortschaltflächen sein:

{
  "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"
          }
        }
      ]
    }
  }
}

die folgendes anzeigen würde:

Ein weiteres Beispiel könnte eine Meldung sein, in der eine Aktion zum Öffnen einer URL vorgeschlagen wird:

{
  "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/"
            }
          }
        }
      ]
    }
  }
}

was zu folgendem Ergebnis führen würde:

Screenshot of an RCS suggested action messageScreenshot of an RCS suggested action message

Obwohl die Struktur dieser beiden Nachrichtentypen unterschiedlich ist, haben Sie vielleicht bemerkt, dass sowohl die reply und action Objekte eine postbackData Eigenschaft enthalten. Der Wert dieser Eigenschaft wird im Zusammenhang mit der eingehenden Nachricht relevant, die ausgelöst wird, wenn der Empfänger mit der vorgeschlagenen Antwort oder der vorgeschlagenen Aktion interagiert. Als nächstes werden wir uns eingehende Nachrichten ansehen.

Eingehende Nachrichten

Wie bereits erwähnt, werden eingehende Nachrichten über einen Webhook empfangen. Es gibt verschiedene Arten von eingehenden Nachrichten, die wir hier nicht alle behandeln werden, aber wir können ein paar Beispiele durchgehen.

Wie bei ausgehenden Nachrichten sind einige Felder in der JSON-Nutzlast für alle Kanäle und Nachrichtentypen gleich. Die Felder to, from, channel, und message_type haben Sie bereits in den obigen Beispielen für ausgehende Nachrichten gesehen. Zusätzlich zu diesen Feldern enthalten eingehende Nachrichten einige weitere Standardfelder; message_uuid das eine eindeutige Kennung für die Nachricht ist, und timestamp der das Datum und die Uhrzeit angibt, zu der die Eingangsnachricht zugestellt wurde. Was über diese Standardeigenschaften hinaus in der Webhook-Nutzlast enthalten ist, hängt vom Nachrichtentyp ab.

Typen wie text, image, video, audio, vcard, file, und location enthalten Daten, die auf der vom Gerät des Kunden gesendeten Nachricht basieren. Bei den Typen, bei denen eine Art von Medien oder Datei gesendet wird, enthält die Nutzlast einen Link zu der Datei auf den Medienservern von Vonage. Der Webhook-Payload für eine Bildnachricht könnte zum Beispiel so aussehen:

{
  "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"
  }
}

Der Inbound reply und eingehende button Nachrichten werden als Ergebnis der Interaktion von Kunden mit vorgeschlagenen Antworten bzw. vorgeschlagenen Aktionen gesendet. Weiter oben in diesem Artikel haben wir die postbackData Eigenschaft in diesen Arten von ausgehenden Nachrichten erwähnt, und hier kommt der für diese Eigenschaft festgelegte Wert ins Spiel.

Betrachtet man das Beispiel der vorgeschlagenen Antwort, so würde der Kunde, wenn er die Schaltfläche mit der Aufschrift They're awesome! die eingehende reply Nachricht liest, würde die Antwort etwa so aussehen, wobei der Wert für postbackData enthalten in der id Eigenschaft des reply Objekts enthalten ist:

{
  "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!"
  }
}

Eine eingehende button Nachricht enthält in ähnlicher Weise den Wert für postbackDataaber dieses Mal wird er als die payload Eigenschaft des button Objekts gesetzt. A button Nachricht, die dadurch ausgelöst wird, dass ein Kunde die URL aus unserer zuvor vorgeschlagenen Aktionsnachricht öffnet, würde etwa so aussehen:

{
  "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"
  }
}

In diesen beiden Fällen kann der Wert von postbackData verwendet werden, um die vom Kunden durchgeführte Aktion zu identifizieren. Darauf aufbauend kann dann eine Logik entwickelt werden, um weitere ausgehende Nachrichten als Teil eines allgemeinen Nachrichtenflusses auszulösen.

Nachbereitung

In diesem Artikel haben wir uns Beispiele für das Senden und Empfangen einzelner Nachrichten verschiedener Typen angesehen. Die potenzielle Stärke von RCS im Vergleich zu Kanälen wie SMS und MMS liegt jedoch in der Kombination dieser verschiedenen Nachrichtentypen zum Aufbau umfangreicher, interaktiver Nachrichtenflüsse, die für viele verschiedene Transaktions- oder Marketinganwendungen genutzt werden können.

RCS bietet das Potenzial für ansprechende Messaging-Erlebnisse, ähnlich wie dies bei Messaging-Apps wie WhatsApp, Facebook Messenger und Viber der Fall ist. Native Unterstützung für RCS auf den Geräten der Kunden bedeutet, dass sie keine spezifische App herunterladen müssen, um diese Nachrichten zu empfangen, wodurch die potenzielle Reichweite von RCS-Messaging im Vergleich zu spezifischen Messaging-App-Kanälen massiv erweitert wird. Der Stolperstein für diese Reichweite war immer die fehlende Geräteunterstützung durch Apple, aber da RCS in iOS 18 unterstützt werden soll, ist jetzt ein guter Zeitpunkt, um mit RCS zu beginnen und es in Ihr Messaging-System zu integrieren.

Wenn Sie von RCS begeistert sind und mehr erfahren möchten, können Sie direkt in unsere Entwickler-Dokumentation. Dort können Sie sich auch alle anderen Kanäle ansehen, die die Messages API bietet, oder unsere vielen anderen Kommunikations-APIs erkunden.

Wir würden uns auch freuen, wenn Sie sich uns auf dem Vonage Entwickler-Slack oder senden Sie uns einen Post auf Xund wir werden auf Sie zurückkommen!

Teilen Sie:

https://a.storyblok.com/f/270183/373x376/e8d3211236/karl-lingiah.png
Karl LingiahRuby-Entwickler Advocate

Karl ist Developer Advocate bei Vonage und kümmert sich um die Wartung unserer Ruby Server SDKs und die Verbesserung der Entwicklererfahrung für unsere Community. Er liebt es zu lernen, Dinge zu entwickeln, Wissen zu teilen und alles, was allgemein mit Webtechnologie zu tun hat.