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 v8.0.0
Temps de lecture : 9 minutes
Beaucoup de choses ont changé dans le SDK Java depuis la dernière annonce post - plus de 17 000 lignes de code en fait ! Bien qu'il s'agisse en grande partie de remaniements internes et d'améliorations de la qualité de vie, il y a quelques changements importants dont il faut être conscient car il s'agit d'une version majeure. Sans plus attendre, plongeons-y !
Commençons par la grande nouvelle : l'API vidéo de Video API de Vonage de Vonage est maintenant officiellement disponible. La transition entre OpenTok à Vonage est en cours depuis un certain temps, d'où les nombreuses versions bêta du SDK. Maintenant que l'API est stable, elle est disponible dans le paquet com.vonage.client.video du SDK Java Server SDK.
S'il y a une chose à retenir de cet article, c'est le fait que le SDK a maintenant migré vers un nouvel emplacement artifactId sur Maven Central. Cela figurait sur la feuille de route depuis 2022, comme en témoignent les diverses versions bêta vers le nouvel emplacement. Le groupId est toujours le même (com.vonage), mais le artifactId est maintenant server-sdk au lieu de client. Cette migration a été signalée dans les métadonnées, de sorte que certains outils et sites web peuvent vous indiquer le nouvel artefact. Vous pouvez voir cet avis sur mvnrepository.com par exemple.
Qu'est-ce qui a motivé ce changement ? La raison principale est d'éviter toute confusion avec d'autres outils publiés sous le com.vonage groupe. Étant donné que nous proposons également des SDK côté client pour le développement d'Android, la dénomination peut créer une certaine confusion, puisqu'il s'agit en fait du SDK côté serveur. client peut créer une certaine confusion, puisqu'il s'agit en fait du SDK côté serveur.
La mise à jour de vos dépendances devrait toujours être un processus simple : remplacez com.vonage:client:7.11.1 (ou la version que vous utilisez actuellement) par com.vonage:server-sdk:8.0.0. Les instructions pour votre système de construction particulier peuvent être trouvées sur le côté droit de la page web Maven Central. la page web Maven Central.
En tant que version sémantique le suggère, cette version comporte quelques modifications de l'API publique du SDK qui sont incompatibles avec les versions précédentes, mais ne vous laissez pas décourager par cette mise à niveau, car la plupart de ces modifications ne devraient pas vous affecter et, si c'est le cas, elles devraient être assez faciles à corriger. Le SDK prend toujours en charge Java 8, et tous les noms de paquetages et de classes sont toujours les mêmes. Cependant, la plupart des membres obsolètes du SDK ont été supprimés comme prévu. Par exemple, le type de message WAPPush le type de message SMS, qui n'est plus pris en charge par l'API. Voici une liste des suppressions et de leurs remplacements.
Comme dans tout projet ayant une certaine histoire, il y a inévitablement du code qui n'est plus utilisé ou pris en charge. Dans le SDK Java, il y a quelques paquets qui ne sont plus maintenus en raison de leur ancienneté et du fait qu'ils ne sont pas utilisés. Le client SNS en est un exemple (l'API est morte depuis longtemps), qui dépendait également de certains utilitaires XML. Le paquet legacyutils, sns et logging ont tous été supprimés. Cela inclut également la configuration de l'URI SNS dans HttpConfig car elle n'est pas utilisée.
L'un des problèmes les plus courants lors de l'utilisation d'une bibliothèque est le conflit de dépendances. J'ai écrit un article sur la façon de résoudre ce problèmemais en général, il est prudent pour les responsables de bibliothèques de minimiser l'empreinte de leurs dépendances dans la mesure du possible.
Un exemple de ce type dans le SDK a été la javax.servlet dépendance. Depuis qu'elle est passée dans l'espace de noms Jakarta, l'utilisation du SDK Java avec les nouvelles versions de Jakarta Servlet est plus difficile. En outre, l'utilisation de cette dépendance était tout à fait inutile, et les classes qui l'utilisaient ne sont plus maintenues. Par conséquent, toutes les méthodes et classes qui faisaient référence à cette dépendance - en particulier, HttpServletRequest - ont été supprimées. Cela inclut le com.vonage.client.voice.servlet et com.vonage.client.sms.callback.AbstractMOServlet. Si vous utilisiez la classe RequestSigning pour vérifier les signatures des messages entrants provenant de l'API SMS, vous pouvez maintenant utiliser la méthode de remplacement verifySignature voir le repo d'extraits de code pour un exemple.
L'autre dépendance qui a été supprimée est jackson-dataformat-hal. Celle-ci fournissait une extension à la bibliothèque Jackson pour la désérialisation des réponses HAL, mais qui n'était fournie que par l'API Account - plus précisément la classe ListSecretsResponse en particulier. Par souci de cohérence avec le reste du SDK, cette extension a été remaniée, et la dépendance n'est donc plus nécessaire.
Les suppressions de l'API Verify comprennent la classe BaseResult qui ne contenait que des codes d'état et qui était inutilisée dans le reste du SDK, et la classe LineTypequi était auparavant obsolète. Cela inclut également les méthodes qui utilisaient LineTypebien sûr. Le champ ipAddress a également été supprimé de AdvancedInsightRequest (dans Number Insight) et de CheckRequest. Il est recommandé d'utiliser le paquet verify2 Il est recommandé d'utiliser le paquetage verify car l'API Verify API v2 de Verify v2 bénéficiera d'une meilleure prise en charge. À ce propos, de nombreux paramètres locaux ont été ajoutés à Verify v2 - à tel point qu'il est devenu difficile d'en assurer la maintenance. Pour cette raison, l'enum custom com.vonage.client.verify2.Locale a été supprimée. A la place, vous devriez utiliser l'outil intégré java.util.Locale. Vous pouvez utiliser l'enum VerificationRequest.Builder#locale(String) par commodité, en fournissant les balises de langue et de région à deux lettres (par exemple, en-gb).
Certaines améliorations de la qualité de vie ont été apportées à la mise en œuvre de l'API Voice, notamment la suppression de méthodes précédemment obsolètes - par exemple, les paramètres de la classe com.vonage.client.voice.Call en faveur de l'utilisation du constructeur qui a été ajouté dans la version 7.3.0. Les deux changements les plus importants concernent VoiceClient.
Tout d'abord, la méthode modifyCall a été supprimée, de même que la méthode ModifyCallResponse. L'implémentation simplifie désormais les actions de modification d'appel avec des appels de méthode directs. Par exemple, pour mettre fin à un appel (raccrocher), il suffit d'utiliser la méthode terminateCall(String) en ne transmettant que l'identifiant de l'appel. Des méthodes similaires existent pour les autres actions (earmuff / unearmuff, mute / unmute).
L'autre changement concerne la méthode downloadRecording . Cette méthode renvoie un Celle-ci renvoyait un objet Recording qui ne permettait que deux choses : récupérer le contenu sous forme d'objet InputStream soit appeler la méthode save(Path) pour le stocker dans un fichier. L'implémentation de cette méthode en interne n'était pas très jolie, elle a donc été simplifiée en fournissant deux nouvelles méthodes sur VoiceClient: void saveRecording(String recordingUrl, Path destination) et byte[] downloadRecordingRaw(String recordingUrl). La première, comme son nom l'indique, sauvegardera l'enregistrement à partir de l'URL donnée (recordingUrl) vers le fichier souhaité (destination). La seconde vous donnera le contenu binaire de l'enregistrement (téléchargé à partir de l'URL ( )) sous la forme d'un tableau d'octets. recordingUrl) sous la forme d'un tableau d'octets, afin que vous puissiez décider de son utilisation si vous ne souhaitez pas le sauvegarder dans un fichier. Par conséquent, la méthode Recording downloadRecording(String recordingUrl) a été supprimée, ainsi que la classe com.vonage.voice.client.Recording classe.
Enfin, le PayAction ainsi que la classe PaymentPrompt ont été supprimés, car ils ne sont plus pris en charge par l'API.
Outre la suppression du code hérité afin de remédier à la dette technique, de nouvelles fonctionnalités ont été ajoutées, décrites ci-dessous. Si vous êtes curieux, le travail de refactorisation interne visant à découpler les implémentations d'API du client HTTP sous-jacent, qui a commencé dans la version 7.7.0, est maintenant terminé, ce qui ouvre la voie à la mise à jour du client à l'avenir - par exemple, pour permettre la prise en charge des requêtes asynchrones. Les tests ont également été migrés vers JUnit 5.
La version 7.8.0 a ajouté la possibilité de définir un délai d'attente personnalisé pour toutes les demandes envoyées par le SDK. Bien que nos API REST répondent généralement dans un délai raisonnable (mesuré en millisecondes plutôt qu'en secondes), certains points d'extrémité peuvent prendre plus de temps en fonction de la quantité de traitement requise et des conditions du réseau. Pour les applications sensibles au facteur temps, il peut être utile de fixer une date limite stricte pour les réponses afin de ne pas attendre plus longtemps que nécessaire sans avoir à créer des threads distincts. Avant la version 7.8.0, le délai par défaut dépendait du système puisqu'il s'agissait de la valeur par défaut du client HTTP Apache sous-jacent (typiquement, 60 secondes). Désormais, ce délai peut être configuré à la milliseconde près à l'aide de la méthode HttpConfig.Builder#timeoutMillis(int) à la milliseconde près. Le délai est désormais de 60 secondes par défaut, quels que soient les paramètres du système.
Certains champs supplémentaires ont été ajoutés pour le flux de travail Silent Auth dans l'API Verify v2. Il s'agit des champs sandbox et redirect_url dans SilentAuthWorkflow, check_url en VerificationResponse. Notre documentation contient plus d'informations sur le workflow Auth silencieuse synchrone et sur Silent Auth sandbox si vous êtes curieux.
AccountClient Améliorations
La classe AccountClient du SDK Java comporte des points de terminaison pour les API Pricing et Account. Cependant, il lui manquait le point de terminaison tarification sortante pour tous les pays qui a été ajoutée depuis la version 7.9.0. Ce point d'accès - qui peut être invoqué avec la méthode AccountClient#listPriceAllCountries(ServiceType) permet de récupérer les informations sur la tarification des services pour tous les pays disponibles.
En outre, des surcharges de méthodes pratiques ont été ajoutées pour la gestion des secrets. Désormais, si vous souhaitez gérer les secrets de votre Account principal (par opposition aux Subaccounts), vous n'avez pas besoin de fournir la clé API à la méthode - celle-ci sera automatiquement dérivée de la méthode d'authentification utilisée pour construire le fichier VonageClient.
Lorsque vous recevez des webhooks de Vonage, il est recommandé de vérifier l'authenticité de la charge utile en validant la signature du jeton. Il s'agissait auparavant d'un processus manuel, mais depuis la version 7.11.0, vous pouvez utiliser la méthode verifySignature(String jwt, String secret) dans VoiceClient et MessagesClient. Celle-ci délègue simplement à la nouvelle méthode Jwt.verifySignature dans l'artefact com.vonage:jwt qui a été mise à jour pour prendre en charge cette fonctionnalité. Désormais, il n'est plus nécessaire d'implémenter la logique d'extraction et de validation de la signature d'une charge utile entrante à l'aide de bibliothèques tierces - il suffit de fournir le JWT et le secret partagé. La méthode renvoie un résultat positif si le jeton a été signé par le secret donné.
Voilà tous les changements que vous devriez connaître dans la version 8.0.0 du SDK Java. N'oubliez pas de surveiller les versions sous les coordonnées com.vonage:server-sdk pour les futures mises à jour ! 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.