Annonce du SDK Java de Vonage v7.0.0

Introduction

Depuis que j'ai rejoint Vonage, je me suis concentré sur l'amélioration du SDK Java de base en remboursant une partie de la dette technique et en veillant à ce qu'il soit à jour avec les dernières spécifications de l'API. Dans ce billet, j'expliquerai certains des principaux changements apportés au SDK et ce qui se profile à l'horizon. J'espère aussi pouvoir vous convaincre de passer à la dernière version 🙂 . Vous pouvez également consulter les notes de version pour chaque version sur GitHub.

Sécurité

Si je ne devais vous donner qu'une seule raison de faire une mise à jour, ce serait la sécurité. Les versions avant la version 6.4.2 sont sensibles à plus de 50 vulnérabilités de sécurité CVE en raison de dépendances obsolètes (principalement Jackson, que nous utilisons pour la sérialisation JSON).

Avant la version 7.0.0, le SDK dépendait d'une petite bibliothèque interne pour travailler avec les JWT. Cette bibliothèque n'avait pas été mise à jour depuis quelques années et était encore sous la marque Nexmo. Elle a maintenant été déplacée vers l'organisation Vonage sur GitHub (https://github.com/Vonage/vonage-jwt-jdk) et vers Maven CentralElle a reçu une nouvelle marque pour plus de cohérence ainsi que des mises à jour de dépendances pour la sécurité.

Nouvelles fonctionnalités

La fonctionnalité la plus notable est l'API Messages, qui a été ajoutée à la version 6.5.0 (pour en savoir plus sur l'annonce ici). J'ai récemment écrit un billet de blog sur l'implémentation de Messages v1 par le SDK Java, alors j'espère que certains d'entre vous qui lisez ceci l'utilisent déjà !J'espère donc que certains d'entre vous lisent cet article et l'utilisent déjà ! Prise en charge du point de terminaison de l'API Pricing API pour récupérer les prix de sortie pour tous les pays a également été ajoutée à la version 6.5.0.

Deux nouvelles fonctionnalités ont été ajoutées à la version 7.0.0. La synthèse vocale Premium est désormais GA, et le drapeau permettant de l'activer a été ajouté à l'écran du TalkAction NCCO. Vous pouvez désormais demander des paiements par téléphone à l'aide de la nouvelle action Pay NCCO. Voici un lien vers les spécifications.

Dépréciations et suppressions

Les suppressions constituent un changement radical, d'où la mise à jour majeure de la version. L'API SMS Search API est depuis longtemps obsolète et a finalement été complètement supprimée. Elle a donc naturellement été supprimée du SDK. L'ancien champ voiceName a également été supprimé afin de décourager l'utilisation de ce type d'application. a également été supprimé afin de décourager son utilisation, car il était déjà obsolète. À la place, vous devez utiliser le nouveau drapeau premium comme décrit ci-dessus. Une refonte interne a également permis de rendre privées certaines classes qui n'auraient jamais dû être accessibles au public (telles que les classes se terminant par Endpoint) ont été rendues privées par le paquet, comme prévu. AbstractClient n'était pas destiné à être accessible au public et ne servait pas à grand-chose en interne, il a donc été supprimé. Il en va de même pour AbstractAuthMethod. Au cas où vous vous seriez appuyé sur Apache Commons (en particulier, lang3, io et logging) soient ajoutées en tant que dépendances implicites, elles ont également été supprimées.

La principale dépréciation à noter concerne l'API Redact API. Bien qu'elle fasse partie du SDK depuis un certain temps, elle n'a jamais quitté le Developer Preview. Par principe, le SDK Java ne prend en charge que les API qui sont "General Availability" dans les versions principales, nous la déprécions donc avec l'intention de la supprimer jusqu'à ce que nous soyons sûrs de pouvoir la prendre pleinement en charge en tant que service GA. À part cela, le champ ipAddress dans AdvancedInsightRequest a été déprécié pour refléter son statut de dépréciation dans la spécification de l'API Number Insight API. Il sera supprimé dans la prochaine version majeure.

Corrections et améliorations

Au fur et à mesure que nos API évoluent, les SDK fortement typés doivent être mis à jour pour refléter les changements dans la spécification. Nous sommes à l'affût des cas où le SDK n'est pas synchronisé avec l'API, mais nous ne parvenons pas toujours à tout détecter, alors n'hésitez pas à nous signaler tout problème et nous essaierons de le corriger dans la prochaine version !

Le CallEvent ne contenait pas le champ call_uuid qui a été ajouté dans la version 6.4.2. L'énumération com.vonage.client.sms.MessageStatus ne contenait pas certains des codes d'erreur décrits dans la spécificationce qui a été corrigé. Il y avait des problèmes avec les classes NCCO, qui n'étaient pas conformes à la spécification. la spécification. En particulier, les actions n'étaient pas correctement définies dans le modèle d'objet, ce qui signifiait que la désérialisation ne fonctionnait pas comme prévu. SipEndpoint Il manquait le champ headers et WebSocketEndpoint limitait de manière incorrecte les valeurs de headers Map aux chaînes de caractères. Les points de terminaison NCCO valident désormais les champs uri à l'aide de java.net.URI. Les constructeurs ont également été rendus privés au niveau du paquetage, de sorte que vous devez les acquérir à partir de la méthode statique builder() pour des raisons de cohérence.

Mise en œuvre de l Number Insight API dans le SDK Java a été mise à jour pour être conforme à la spécification. Les problèmes concernaient principalement des champs manquants ou des champs appartenant à la mauvaise classe (certaines fonctionnalités ont été déplacées d'Advanced à Standard insight, par exemple). La documentation a également été améliorée et ajoutée là où elle manquait. Certaines des énumérations internes (par exemple, dans la section AdvancedInsightResponse) ont été déplacées dans des fichiers distincts, de sorte que si une fonctionnalité est déplacée, par exemple, d'Advanced à Standard, il ne sera pas nécessaire de procéder à une modification radicale à l'avenir. Des valeurs supplémentaires pour InsightStatus ont été ajoutées. Pour la version synchrone de AdvancedInsightRequestun nouveau champ booléen realTimeData a été ajouté. S'il a pour valeur truevous obtiendrez le statut en AdvancedInsightResponse.

Quelques corrections ont été apportées à l'API Messages. Plus particulièrement dans la section WhatsappTemplateRequest's parameters que la la spécification présentait de manière trompeuse comme étant un List<Map, String, ?>> alors qu'il devrait s'agir d'un List<String>. Une autre solution consiste à utiliser les champs policy et locale . Le premier n'ayant qu'une seule valeur valide à l'heure actuelle, il est facultatif dans l'API. Le second était plus fondamentalement défectueux dans la version 6.5.0 puisqu'il empêchait l'utilisation de locales de moins de 4 caractères. De plus, la documentation n'indiquait pas clairement quelles étaient les valeurs valides. Pour éviter toute confusion, la liste complète des langues prises en charge par WhatsApp a été ajoutée sous forme d'énumération. Ainsi, plutôt que de transmettre une chaîne potentiellement invalide, vous n'avez plus besoin de chercher ce qui est pris en charge - tout est énuméré pour vous dans le SDK ! Plus généralement, la validation par le SDK des numéros d'expéditeur (c'est-à-dire le champ from ) était incorrecte pour les SMS, les MMS et WhatsApp. Les expéditeurs de SMS et de MMS peuvent désormais contenir des caractères alphanumériques (c'est-à-dire des ID), tandis que l'expéditeur WhatsApp doit être un numéro de WhatsApp Business Account.

Plus généralement, le SDK est un peu plus ordonné en interne (en termes de qualité du code, de cohérence, etc.) et a une couverture de test plus élevée. Du point de vue de l'utilisateur, les autres améliorations diverses sont le paramétrage de Content-Type, Accept et User-Agent dans les requêtes sortantes, ainsi que l'utilisation explicite de l'encodage UTF-8. Pour ceux qui s'interrogent sur la compatibilité, nous nous efforçons de prendre en charge Java 8 pendant un certain temps, à moins qu'il n'y ait une raison plus impérieuse, du point de vue de la maintenabilité, de passer à 11 ou 17. Le SDK a été testé avec le JDK 18, de sorte que toute version moderne de Java est actuellement prise en charge.

Feuille de route

Outre la maintenance de routine visant à garantir la cohérence de l'implémentation actuelle avec les spécifications de l'API et les correctifs généraux, la prochaine grande nouveauté pour le SDK Java est la nouvelle Video APIqui est actuellement en version bêta. Le OpenTok Java SDK finira par disparaître. Au lieu d'avoir des dépôts, des artefacts, des versions, des bases de code, etc. séparés, nous avons décidé de rationaliser l'expérience de l'utilisateur en intégrant la fonctionnalité Video directement dans nos SDK principaux. Nous allons déployer la prise en charge de cette fonctionnalité dans les SDK de manière progressive par le biais de versions bêta. Si vous souhaitez mettre la main sur des fonctionnalités vidéo, gardez un œil sur les sites suivants Maven Central pour les versions bêta du SDK Java !

Bien sûr, dans l'intervalle, il y aura toujours des versions principales avec des correctifs, des corrections et même de nouvelles fonctionnalités GA, mais dans l'intervalle, nous travaillerons sur l'implémentation de l'API Video dans les SDKs. Étant donné que l'architecture du code d'OpenTok est tellement différente de celle du SDK principal, il s'agira pour moi d'une réécriture complète. À plus long terme, je suis conscient que certains utilisateurs du SDK Java veulent des requêtes et des réponses asynchrones. C'est le prochain point de ma liste d'améliorations majeures du SDK, alors restez à l'écoute.

Signature

C'est tout pour l'instant ! Si vous rencontrez des problèmes ou si vous avez des suggestions d'amélioration, n'hésitez pas à soulever un problème sur GitHubou de nous contacter sur Twitter ou de passer par notre Communauté Slack. J'espère que vous aurez une bonne expérience en utilisant les API de Vonage avec la dernière version du SDK Java !