Partager:
){kind=small}
Sina est développeur Java chez Vonage. Il est issu d'une formation universitaire et est généralement curieux de tout ce qui touche aux voitures, aux ordinateurs, à la programmation, à la technologie et à la nature humaine. Pendant son temps libre, on peut le trouver en train de marcher ou de jouer à des jeux vidéo compétitifs.
Annonce du SDK Java de Vonage v7.7.0
La version 7.7.0 du SDK Java de Vonage est maintenant disponible ! Ce billet décrit les changements et ce à quoi on peut s'attendre dans un avenir proche.
Entre mars et août 2023, il y a eu sept versions du SDK Java de Vonage avec plus de 35 000 lignes de code modifiées depuis la version 7.1.1 de 2022. Comme le schéma de versionnement sémantique suggère que la mise à jour vers la dernière version devrait être rétrocompatible. Si vous utilisez une version antérieure à la 7.0.0, reportez-vous à l'annonce de la annonce de la v7.0.0 pour un résumé des changements. Dans cet article, j'espère vous convaincre de passer à la dernière version du SDK en résumant les mises à jour depuis la v7.0.0.
Les principales nouveautés des dernières versions sont les nouvelles API qui sont entrées dans le statut de disponibilité générale et qui sont donc prises en charge dans nos SDK de serveur. Les API suivantes sont désormais entièrement prises en charge dans le SDK Java :
Verify v2: La nouvelle version de l'API Verify ajoute des canaux supplémentaires, comme WhatsApp (qui peut même être sans code), l'e-mail et la voix, ainsi que le traditionnel SMS pour la mise en œuvre de l'authentification multifactorielle dans votre application. En outre, les flux de travail de vérification ont maintenant des fallbacks, de sorte que vous pouvez ajouter un délai d'attente pour chaque canal et essayer une méthode d'authentification différente ou un numéro de téléphone à contacter en guise de sauvegarde.
Réunions: Solution low-code permettant de créer et de gérer dynamiquement des salles de réunion. Si vous avez déjà utilisé Vonage Business Cloudcette API vous permet de programmer l'approvisionnement et de personnaliser l'application VBC en fonction des besoins de votre organisation.
Subaccounts: Cette API vous permet de créer et de gérer des sous-comptes, ce qui peut être utile pour séparer & suivre l'utilisation, la facturation et les numéros attribués en fonction de l'unité commerciale ou du département. Notez que cette fonctionnalité doit être activée sur votre Account.
Outre les nouvelles API, les améliorations les plus notables concernent l'API Messages. Depuis la version 7.1.0, vous pouvez désormais utiliser l'outil Sandbox de l'API Messages à partir du SDK Java, ce qui vous permet de tester l'envoi de messages via WhatsApp, Viber et Facebook Messenger sans avoir à configurer un Account avec chacune de ces plateformes. De nouveaux types de messages sont désormais disponibles :
WhatsApp célibataire et multi Messages sur les produits
Ces types de messages dédiés à WhatsApp facilitent l'envoi déclaratif de lieux, d'autocollants et de produits sans avoir à construire un type de message personnalisé. Bien sûr, l'API de WhatsApp est riche et vous pouvez toujours utiliser des types de messages personnalisés - par exemple, pour envoyer un contact.
Vous pouvez désormais inclure des boutons d'action dans vos messages texte et image Viber. Un autre ajout notable est une meilleure prise en charge des messages entrants. L'API Messages permet non seulement d'envoyer des messages, mais aussi d'en recevoir. Cela se fait par l'intermédiaire de webhooks. Lorsque vous configurez un écouteur pour les messages entrants, les données envoyées à votre serveur d'application (comme décrit dans la spécification de l'API) peuvent maintenant être désérialisées dans un objet com.vonage.client.messages.InboundMessage objet. Il en va de même pour Message Status webhookqui peut être désérialisé via la classe com.vonage.client.messages.MessageStatus . Si vous utilisez déjà des webhooks pour inspecter l'état des messages, vous serez heureux d'apprendre que la désérialisation des horodatages a été corrigée.
L'implémentation du SDK de l Application API a été mise à jour avec une documentation améliorée et des champs manquants ont été ajoutés. En particulier, les capacités Voice ont été mises à jour avec les éléments suivants conversations_ttl, signed_callbacks, et region ont été ajoutés. Vous pouvez désormais définir les champs connection_timeout et socket_timeout dans Webhook - qui dispose désormais d'un Builder pour faciliter la construction. Le type fallback_answer_url a également été ajouté. Pour plus de commodité, vous pouvez désormais lister facilement toutes les applications en utilisant la nouvelle méthode ApplicationClient::listAllApplications() nouvelle méthode. Par souci d'uniformité, toutes les réponses d'erreur 4xx ou 500 provenant de l'API seront désormais enveloppées dans un élément de type ApplicationResponseException comme pour nos autres nouvelles API, afin que vous puissiez plus facilement inspecter et examiner les détails de l'erreur.
Comme les utilisateurs sont liés à une application particulière, nous avons récemment ajouté des points d'accès à la gestion des utilisateurs à l'API d'application. des points de terminaison pour la gestion des utilisateurs à l'API d'application. L'API elle-même est assez simple, fournissant des opérations CRUD pour gérer les utilisateurs dans vos Applications. Actuellement, ces opérations sont utilisées par l'API Conversation API. Un utilisateur peut être associé à plusieurs canaux de contact : SMS, WhatsApp, Viber, Facebook Messenger, PSTN, SIP, VBC et Websocket. Le SDK Java prend en charge la gestion des utilisateurs grâce au nouveau paquetage com.vonage.client.users nouvellement ajouté.
La mise en œuvre de l'API Voice (com.vonage.client.voice.*) a également fait l'objet de quelques modifications notables. Il s'agit notamment de petites corrections telles que la sérialisation d'un champ (en particulier, randomFromNumber dans Call) et la désérialisation du type d'extrémité app type de point d'extrémité.
Le changement le plus important, cependant, est l'utilisation du modèle Builder pour construire des objets. Cela correspond mieux à la manière dont d'autres API gèrent la construction des corps de requête. En particulier, la création d'un appel (via la méthode VoiceClient#createCall(Call) ) devrait être plus simple et plus déclarative, car l'objet Call dispose désormais d'une fonction Builder que vous pouvez utiliser pour définir les propriétés de l'appel, plutôt que d'essayer de vous rappeler lequel des nombreux constructeurs utiliser. Cela simplifie également l'ajout de nouveaux paramètres et de nouvelles fonctionnalités pour les propriétés initiales de l'appel. Une autre classe qui a reçu le traitement Builder est TalkPayload (telle qu'elle est utilisée dans VoiceClient#startTalk). La même idée s'applique : plutôt que d'essayer de trouver la signature de la méthode avec la combinaison de paramètres souhaitée, vous pouvez maintenant appeler VoiceClient#startTalk(String uuid, TalkPayload properties) using TalkPayload.builder() pour définir les propriétés qui vous intéressent.
Par conséquent, les autres variantes de startTalk ont été dépréciées et seront supprimées dans la prochaine version majeure. À ce propos, les paramètres de la classe Call ont également été abandonnés au profit de l'utilisation du Builder. Pour mettre un peu plus d'ordre, certaines classes internes ont été rendues privées, et celles qui pourraient potentiellement être utilisées (CallModifier et ModifyCallPayload) ont été dépréciées.
Outre les corrections et les remaniements, de nouvelles fonctionnalités ont été ajoutées. Les plus notables sont Détection avancée des machines (qui peut être activée à l'aide de la méthode Call.Builder#advancedMachineDetection ). Si elle est spécifiée, cette fonction remplace la fonction standard de détection des machines. Elle est beaucoup plus précise dans la détection des messages vocaux et est une fonction premium, donc facturée par appel. Une autre nouvelle fonction est Premium Text-to-Speechqui peut être sélectionnée en réglant TalkPayload.Builder#premium(boolean) à true. Cette fonction est également disponible sur le TalkAction NCCO. Ces voix de qualité supérieure ont un son plus naturel et sont facturées en fonction du nombre de caractères. Consultez notre documentation pour les développeurs pour obtenir la liste des langues prises en charge.
Enfin, quelques ajouts ont été effectués, qui manquaient à la mise en œuvre de l'API dans le SDK. La possibilité d'ajuster le niveau de volume de la synthèse vocale a été ajoutée à TalkPayload (disponible via le Builder). Il peut être réglé dans une plage de -1 à 1, 0 étant la valeur par défaut, -1 la valeur la plus faible et 1 la valeur la plus élevée. Le point de terminaison point de terminaison VBC a également été ajouté au SDK.
Si vous mettez à jour à partir de la version 7.0.0 ou d'une version antérieure, l'API Verify v1 classique a fait l'objet de quelques améliorations en termes de qualité de vie. Bien que nous encouragions les utilisateurs à migrer vers la nouvelle API Verify v2, le SDK prend toujours en charge l'API Verify classique. La dernière version du SDK Java est désormais plus en phase avec la spécification. Notamment, les champs manquants ont été ajoutés, le Bring Your Own PIN est désormais pris en charge et les champs inutilisés ont été supprimés.
Bien entendu, l'un des avantages de la mise à jour vers la dernière version du SDK est la sécurité. Bien que le SDK Java ait relativement peu de dépendances, les principales - Jackson et Apache HTTP Client - sont particulièrement sensibles aux CVE, et il est donc important de les maintenir à jour. Avant chaque version du SDK Java, la version de chaque dépendance est vérifiée pour s'assurer qu'il s'agit de la dernière version mineure ou corrective disponible. Cela étant dit, la suppression des dépendances qui ne sont pas nécessaires pour réduire le risque de failles de sécurité est également une bonne pratique.
Dans les versions récentes, javax.servlet et javax.xml.bind ont été supprimées car le SDK n'en avait pas besoin. Pour des raisons de compatibilité, la dépendance jakarta.servlet (qui remplace javax.servlet) est facultative mais, en théorie, ne devrait jamais être requise. Certaines classes internes ont une dépendance implicite à l'égard de javax.servlet.HttpServletRequest. Toutefois, ces classes ont été dépréciées de sorte que la dépendance peut être complètement supprimée. En particulier, si vous utilisez com.vonage.client.sms.callback.AbstractMOServleta été dépréciée et sera supprimée dans la prochaine version majeure.
Le prochain grand changement apporté au SDK sera très probablement une mise à niveau du Client HTTP Apache 4 vers 5. Avant cela, une refonte interne majeure est nécessaire. Actuellement, chaque sous-client (c'est-à-dire les clients utilisés pour chaque API, par exemple, VoiceClient) est composé de plusieurs points d'extrémité. Il s'agit de classes internes qui gèrent la logique d'envoi de votre demande au bon point de terminaison de l'API et qui renvoient la réponse désérialisée. Cette logique est étroitement liée à l'implémentation du client HTTP sous-jacent, ce qui rend la migration vers un autre client très difficile. Je travaille actuellement sur le découplage de l'implémentation de ces points de terminaison, ce qui devrait également réduire le nombre de chaudières. Des progrès ont été réalisés dans la version 7.7.0, avec la migration de plusieurs API vers cette nouvelle approche. Ainsi, vous pouvez remarquer de nouvelles interfaces publiques comme Jsonable et QueryParamsRequest dans certains objets de domaine.
Une fois ce travail effectué pour toutes les API supportées par le SDK, la migration sera beaucoup plus simple car il n'y aura qu'un seul endroit pour modifier la logique sous-jacente plutôt que chaque point de terminaison d'API (et n'oublions pas les tests !) dans le SDK. Nous serons alors en mesure de migrer vers Apache HttpClient 5. Cela sera bénéfique non seulement pour la sécurité mais aussi pour préparer le terrain pour l'une des fonctionnalités les plus demandées : les requêtes non bloquantes (asynchrones).
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 !
Partager:
Sina est développeur Java chez Vonage. Il est issu d'une formation universitaire et est généralement curieux de tout ce qui touche aux voitures, aux ordinateurs, à la programmation, à la technologie et à la nature humaine. Pendant son temps libre, on peut le trouver en train de marcher ou de jouer à des jeux vidéo compétitifs.