Share:
){kind=small}
Sina ist Java Developer Advocate bei Vonage. Er hat einen akademischen Hintergrund und ist generell neugierig auf alles, was mit Autos, Computern, Programmierung, Technologie und der menschlichen Natur zu tun hat. In seiner Freizeit geht er gerne spazieren oder spielt wettbewerbsfähige Videospiele.
Ankündigung des Vonage Java SDK v7.7.0
Version 7.7.0 des Vonage Java SDK ist jetzt verfügbar! Dieser Beitrag beschreibt die Änderungen und was Sie in naher Zukunft erwarten können.
Zwischen März und August 2023 gab es sieben Versionen des Vonage Java SDK mit über 35.000 Zeilen Codeänderungen seit der Version 7.1.1 aus dem Jahr 2022. Da das semantischen Versionierungsschema suggeriert, sollte ein Update auf die neueste Version abwärtskompatibel sein. Wenn Sie eine ältere Version als 7.0.0 verwenden, lesen Sie bitte die v7.0.0 Ankündigung für eine Zusammenfassung der Änderungen. In diesem Artikel hoffe ich, Sie davon zu überzeugen, auf die neueste Version des SDK zu aktualisieren, indem ich die Aktualisierungen seit Version 7.0.0 zusammenfasse.
Die wichtigste Neuigkeit der letzten Versionen sind die neuen APIs, die den Status der allgemeinen Verfügbarkeit erreicht haben und somit in unseren Server-SDKs unterstützt werden. Die folgenden APIs werden nun vollständig im Java-SDK unterstützt:
Überprüfen v2: Die neue Version der Verify-API fügt zusätzliche Kanäle hinzu, wie z. B. WhatsApp (das sogar codelos sein kann), E-Mail und Sprache, sowie die traditionelle SMS für die Implementierung der Multi-Faktor-Authentifizierung in Ihrer Anwendung. Darüber hinaus haben Verifizierungs-Workflows jetzt Fallbacks, so dass Sie eine Zeitüberschreitung für jeden Kanal hinzufügen und eine andere Authentifizierungsmethode oder Telefonnummer als Backup versuchen können.
Begegnungen: Low-Code-Lösung, mit der Sie dynamisch Besprechungsräume erstellen und verwalten können. Wenn Sie jemals die Vonage Business Cloudverwendet haben, können Sie mit dieser API die VBC-Anwendung programmatisch bereitstellen und an die Bedürfnisse Ihres Unternehmens anpassen.
Unterkonten: Mit dieser API können Sie Unterkonten erstellen und verwalten, die für die Trennung und Verfolgung von Nutzung, Abrechnung und zugewiesenen Nummern je nach Geschäftseinheit oder Abteilung nützlich sein können. Beachten Sie, dass diese Funktion in Ihrem Konto aktiviert sein muss.
Neben den neuen APIs sind die bemerkenswertesten Verbesserungen bei der Nachrichten-API zu finden. Seit 7.1.0 können Sie jetzt die Nachrichten-API-Sandbox aus dem Java SDK verwenden, mit der Sie das Versenden von Nachrichten über WhatsApp, Viber und Facebook Messenger testen können, ohne ein Geschäftskonto bei jeder dieser Plattformen einrichten zu müssen. Neue Nachrichtentypen sind jetzt verfügbar:
Diese speziellen Nachrichtentypen für WhatsApp erleichtern das deklarative Senden von Orten, Stickern und Produkten, ohne dass ein benutzerdefinierter Nachrichtentyp erstellt werden muss. Natürlich ist die WhatsApp-API reichhaltig, und Sie können immer noch benutzerdefinierte Nachrichtentypen verwenden - zum Beispiel, um einen Kontakt zu senden.
Sie können jetzt auch Aktionsschaltflächen in Ihre Viber-Text- und Bildnachrichten einfügen. Eine weitere bemerkenswerte Ergänzung ist die bessere Unterstützung für eingehende Nachrichten. Die Nachrichten-API dient nicht nur zum Senden, sondern auch zum Empfangen von Nachrichten. Dies geschieht über Webhooks. Wenn Sie einen Listener für eingehende Nachrichten einrichten, werden die an Ihren Anwendungsserver gesendeten Daten (wie in der in der API-Spezifikation) können nun in ein com.vonage.client.messages.InboundMessage Objekt deserialisiert werden. Das gleiche gilt für Nachrichtenstatus-Webhook, der über die Klasse "Message Status" deserialisiert werden kann. com.vonage.client.messages.MessageStatus Klasse deserialisiert werden kann. Wenn Sie bereits Webhooks zur Überprüfung des Nachrichtenstatus verwenden, wird es Sie freuen zu hören, dass die Deserialisierung von Zeitstempeln nun behoben wurde.
Die SDK-Implementierung der Anwendungs-API wurde aktualisiert, die Dokumentation verbessert und fehlende Felder hinzugefügt. Insbesondere die Sprachfähigkeiten wurden durch die conversations_ttl, signed_callbacks, und region Felder ergänzt. Sie können nun die Felder connection_timeout und socket_timeout Felder in Webhook - die jetzt einen Builder für eine einfachere Konstruktion hat. Der fallback_answer_url Webhook-Typ wurde ebenfalls hinzugefügt. Der Einfachheit halber können Sie jetzt alle Anwendungen mit der neuen ApplicationClient::listAllApplications() Methode auflisten. Aus Gründen der Einheitlichkeit werden alle 4xx- oder 500-Fehlerantworten von der API nun in ein ApplicationResponseException verpackt, wie bei unseren anderen neuen APIs, so dass Sie die Details des Fehlers leichter überprüfen und untersuchen können.
Da Benutzer an eine bestimmte Anwendung gebunden sind, haben wir kürzlich Endpunkte für die Benutzerverwaltung zur Anwendungs-API hinzugefügt. Die API selbst ist recht einfach und bietet CRUD-Vorgänge für die Verwaltung von Benutzern in Ihren Anwendungen. Derzeit werden diese von der Konversations-API. Einem Benutzer können mehrere Kontaktkanäle zugeordnet werden - dies sind SMS, WhatsApp, Viber, Facebook Messenger, PSTN, SIP, VBC und Websocket. Das Java SDK unterstützt die Benutzerverwaltung durch das neu hinzugefügte com.vonage.client.users Paket.
Die Implementierung der Sprach-API (com.vonage.client.voice.*) erhielt ebenfalls einige bemerkenswerte Änderungen. Dazu gehören kleine Korrekturen wie die Serialisierung eines Feldes (insbesondere, randomFromNumber in Call) und die Deserialisierung des app Endpunkttyps.
Die größte Änderung ist jedoch die Umstellung auf die Verwendung des Builder-Musters zur Konstruktion von Objekten. Dies entspricht eher der Vorgehensweise anderer APIs bei der Erstellung von Anforderungskörpern. Insbesondere die Erstellung eines Aufrufs (über die VoiceClient#createCall(Call) Methode) sollte nun unkomplizierter und deklarativer sein, da das Call Objekt jetzt ein Builder hat, mit dem man die Eigenschaften des Aufrufs festlegen kann, anstatt zu versuchen, sich zu merken, welchen der vielen Konstruktoren man verwenden muss. Dies vereinfacht auch das Hinzufügen neuer Parameter und Funktionen für die anfänglichen Aufrufeigenschaften. Eine weitere Klasse, die die Builder-Behandlung erhalten hat, ist TalkPayload (wie verwendet in VoiceClient#startTalk). Die gleiche Idee gilt: Anstatt zu versuchen, die Methodensignatur mit der gewünschten Kombination von Parametern zu finden, können Sie jetzt VoiceClient#startTalk(String uuid, TalkPayload properties) mit TalkPayload.builder() aufrufen, um die gewünschten Eigenschaften zu definieren.
Folglich wurden die anderen Varianten von startTalk veraltet und werden in der nächsten Hauptversion entfernt. Apropos, die Setter der Klasse Call Klasse sind ebenfalls veraltet und werden durch den Builder ersetzt. Um die Dinge weiter aufzuräumen, wurden einige interne Klassen paketprivat gemacht, und diejenigen, die potenziell verwendet werden könnten (CallModifier und ModifyCallPayload) wurden verpönt.
Neben Korrekturen und Überarbeitungen gibt es auch neue Funktionen. Am bemerkenswertesten ist Erweiterte Maschinenerkennung (die mit der Methode Call.Builder#advancedMachineDetection Methode eingestellt werden kann). Wenn diese Funktion angegeben wird, hat sie Vorrang vor der Standardfunktion zur Erkennung von Anrufbeantwortern. Sie ist wesentlich genauer bei der Erkennung von Sprachnachrichten und ist eine Premiumfunktion, d. h. sie ist pro Anruf kostenpflichtig. Eine weitere neue Funktion ist Premium Text-to-Speech, die durch die Einstellung TalkPayload.Builder#premium(boolean) auf true. Diese Funktion ist auch auf dem TalkAction NCCO-Builder verfügbar. Diese Premium-Stimmen klingen natürlicher und werden nach der Anzahl der Zeichen abgerechnet. Konsultieren Sie unsere Entwicklerdokumentation für eine Liste der unterstützten Sprachen.
Schließlich wurden einige Ergänzungen vorgenommen, die in der Implementierung der API im SDK fehlten. Die Möglichkeit, den Lautstärkepegel von Text-to-Speech einzustellen, wurde hinzugefügt zu TalkPayload (verfügbar über den Builder). Diese kann in einem Bereich von -1 bis 1 eingestellt werden, wobei 0 die Standardeinstellung ist, -1 die leiseste und 1 die lauteste. Der VBC-Endpunkt wurde ebenfalls in das SDK aufgenommen.
Wenn Sie von 7.0.0 oder einer älteren Version aktualisieren, wurden einige Qualitätsverbesserungen an der klassischen Verify v1 API vorgenommen. Obwohl wir die Benutzer ermutigen, auf die neue Verify v2 API zu migrieren, unterstützt das SDK weiterhin die klassische Verify API. Die neueste Version des Java-SDK ist nun besser auf die der Spezifikation. Insbesondere wurden fehlende Felder hinzugefügt, Bring Your Own PIN wird jetzt unterstützt, und nicht verwendete Felder wurden abgeschafft.
Einer der Vorteile eines Upgrades auf die neueste Version des SDK ist natürlich die Sicherheit. Obwohl das Java SDK nur relativ wenige Abhängigkeiten hat, sind die wichtigsten - Jackson und Apache HTTP Client - besonders anfällig für CVEs, daher ist es wichtig, diese auf dem neuesten Stand zu halten. Vor jeder Veröffentlichung des Java SDK wird jede Abhängigkeitsversion geprüft, um sicherzustellen, dass es sich um die neueste verfügbare Minor- oder Patch-Version handelt. Das Entfernen von Abhängigkeiten, die nicht erforderlich sind, um das Risiko von Sicherheitslücken zu verringern, ist ebenfalls eine gute Praxis.
In neueren Veröffentlichungen, javax.servlet und javax.xml.bind entfernt, da das SDK sie nicht mehr benötigte. Aus Kompatibilitätsgründen wird die jakarta.servlet Abhängigkeit (die die Abhängigkeit javax.servlet) optional, sollte aber theoretisch nie erforderlich sein. Einige interne Klassen haben eine implizite Abhängigkeit von javax.servlet.HttpServletRequest. Diese wurden jedoch veraltet, so dass die Abhängigkeit vollständig entfernt werden kann. Insbesondere, wenn Sie com.vonage.client.sms.callback.AbstractMOServletverwenden, ist diese nun veraltet und wird in der nächsten Hauptversion entfernt.
Die nächste große Änderung am SDK wird höchstwahrscheinlich ein Upgrade von Apache HTTP Client 4 auf 5 sein. Bevor dies geschehen kann, ist ein größeres internes Refactoring erforderlich. Derzeit besteht jeder Subclient (d.h. die Clients, die für jede API verwendet werden, z.B., VoiceClient) aus mehreren Endpunkten zusammen. Dabei handelt es sich um interne Klassen, die die Logik für das Senden Ihrer Anfrage an den richtigen API-Endpunkt und die Rückgabe der deserialisierten Antwort übernehmen. Diese Logik ist eng an die zugrunde liegende HTTP-Client-Implementierung gekoppelt, was die Migration zu einem anderen Client sehr schwierig macht. Ich arbeite derzeit daran, die Implementierung dieser Endpunkte zu entkoppeln, was auch den Aufwand für die Implementierung reduzieren sollte. In Version 7.7.0 wurden einige Fortschritte erzielt und mehrere APIs auf diesen neuen Ansatz migriert. Daher werden Sie vielleicht einige neue öffentliche Schnittstellen wie Jsonable und QueryParamsRequest in einigen Domänenobjekten.
Sobald diese Arbeit für alle vom SDK unterstützten APIs erledigt ist, wird die Migration viel einfacher sein, da die zugrundeliegende Logik an einer einzigen Stelle geändert werden kann, im Gegensatz zu jedem einzelnen API-Endpunkt (und vergessen wir nicht die Tests!) im SDK. Wir werden dann in der Lage sein, auf Apache HttpClient 5 zu migrieren. Dies dient nicht nur der Sicherheit, sondern legt auch den Grundstein für eine der am häufigsten geforderten Funktionen: nicht-blockierende (asynchrone) Anfragen.
Das war's für den Moment! Wenn Sie auf irgendwelche Probleme stoßen oder Verbesserungsvorschläge haben, können Sie gerne einen Fehler auf GitHub zu meldenoder erreichen Sie uns auf Twitter oder schauen Sie bei unserem Gemeinschaft Slack. Ich hoffe, Sie haben viel Spaß bei der Nutzung der Vonage APIs mit der neuesten Version des Java SDK!
Share:
Sina ist Java Developer Advocate bei Vonage. Er hat einen akademischen Hintergrund und ist generell neugierig auf alles, was mit Autos, Computern, Programmierung, Technologie und der menschlichen Natur zu tun hat. In seiner Freizeit geht er gerne spazieren oder spielt wettbewerbsfähige Videospiele.