Compartir:
){kind=small}
Sina es promotora de desarrollo Java en Vonage. Procede del mundo académico y, en general, siente curiosidad por todo lo relacionado con los coches, los ordenadores, la programación, la tecnología y la naturaleza humana. En su tiempo libre, se le puede encontrar paseando o jugando a videojuegos de competición.
Anunciamos Vonage Java SDK v8.0.0
Tiempo de lectura: 8 minutos
Han cambiado muchas cosas en el SDK de Java desde el último anuncio - más de 17.000 líneas de código ¡de hecho! Aunque gran parte de esto es refactorización interna y mejoras en la calidad de vida, hay algunos cambios importantes a tener en cuenta, ya que esta es una versión importante. Sin más preámbulos, ¡vamos a ello!
Empecemos por la gran noticia: la API de Video de Vonage ha sido lanzada oficialmente. La transición de OpenTok a Vonage se ha estado gestando durante algún tiempo, de ahí las numerosas versiones beta del SDK. Ahora que la API es estable, está disponible en el com.vonage.client.video paquete del SDK de servidor Java.
Si hay una cosa que sacar de este artículo, es el hecho de que el SDK ha migrado ahora a un nuevo artifactId en Maven Central. Esto ha estado en la hoja de ruta desde 2022, como lo demuestran las varias versiones beta a la nueva ubicación. La dirección groupId sigue siendo el mismo (com.vonage), pero el artifactId es ahora server-sdk en lugar de client. Esta migración se ha señalado en los metadatos, por lo que algunas herramientas y sitios web pueden indicarle el nuevo artefacto. Puede ver este aviso en mvnrepository.com por ejemplo.
¿Qué ha motivado este cambio? La razón principal es evitar confusiones con otras herramientas publicadas bajo el com.vonage grupo. Dado que también ofrecemos SDK del lado del cliente para el desarrollo de Android, la denominación client nombre puede crear cierta confusión, ya que es, de hecho, el SDK del lado del servidor.
Actualizar sus dependencias debería seguir siendo un proceso sencillo: sustituya com.vonage:client:7.11.1 (o la versión que esté utilizando) por com.vonage:server-sdk:8.0.0. Las instrucciones para su sistema de construcción en particular se puede encontrar en la parte derecha de la página web de Maven Central.
Como la versión semántica hay algunos cambios incompatibles con versiones anteriores en la API pública del SDK en esta versión, pero no deje que eso le desanime a actualizar, ya que es poco probable que la mayoría de ellos le afecten y, si lo hacen, deberían ser bastante fáciles de solucionar. El SDK sigue siendo compatible con Java 8, y todos los nombres de paquetes y clases siguen siendo los mismos. Sin embargo, la mayoría de los miembros obsoletos del SDK se han eliminado según lo previsto. Por ejemplo, el tipo de mensaje WAPPush tipo de mensaje SMS, que ya no es compatible con la API. He aquí una lista de las eliminaciones y sus sustituciones.
Como ocurre con cualquier proyecto que tiene algo de historia, inevitablemente habrá código que ya no se utilice o no reciba soporte. En el SDK de Java, había unos cuantos paquetes que ya no se mantienen debido a su antigüedad y al hecho de que no se utilizan. El cliente SNS es un ejemplo de ello (la API hace tiempo que murió), que también dependía de algunas utilidades XML. El sitio legacyutils, sns y logging han sido eliminados. Esto incluye también la configuración SNS URI en HttpConfig ya que no se utiliza.
Uno de los problemas más comunes cuando se utiliza cualquier biblioteca son los conflictos de dependencia. Escribí un artículo sobre cómo resolver estopero, en general, es prudente que los responsables de las bibliotecas minimicen su huella de dependencia en la medida de lo posible.
Un ejemplo de ello en el SDK ha sido la javax.servlet dependencia. Dado que ahora se ha trasladado al espacio de nombres de Jakarta, hace que utilizar el SDK de Java con versiones más recientes de Jakarta Servlet sea más complicado. Además, el uso de esta dependencia era bastante innecesario, y las clases que la utilizaban ya no se mantienen. Por lo tanto, todos los métodos y clases que hacían referencia a esto - específicamente, HttpServletRequest - han sido eliminados. Esto incluye el paquete com.vonage.client.voice.servlet y el paquete com.vonage.client.sms.callback.AbstractMOServlet. Si estaba utilizando la clase RequestSigning para verificar las firmas de los mensajes entrantes de la SMS API, ahora puede utilizar el método de sustitución verifySignature véase el repositorio de fragmentos de código para ver un ejemplo.
La otra dependencia que se ha eliminado es jackson-dataformat-hal. Esto proporcionaba una extensión de la biblioteca Jackson para deserializar las respuestas HAL, pero que sólo era por la API de Account - específicamente la clase ListSecretsResponse . Por coherencia con el resto del SDK, esto ha sido refactorizado, por lo que la dependencia ya no es necesaria.
Entre las supresiones de la Verify API se incluyen la clase BaseResult que sólo contenía códigos de estado y no se utilizaba en el resto del SDK, y la clase LineTypeque ya estaba obsoleta. Esto también incluye los métodos que utilizaban LineTypepor supuesto. El campo ipAddress también se ha eliminado de AdvancedInsightRequest (en Number Insight) y de CheckRequest. Se recomienda utilizar el paquete verify2 en lugar de verify ya que la Verify v2 API recibirá más soporte. Hablando de eso, se han añadido numerosas localizaciones a Verify v2, tantas que mantenerlas al día se ha convertido en una carga de mantenimiento. Por este motivo, se ha eliminado la lista com.vonage.client.verify2.Locale se ha eliminado. En su lugar, debe utilizar la función java.util.Locale. Puede utilizar el VerificationRequest.Builder#locale(String) por conveniencia, proporcionando las etiquetas de idioma y región de dos letras (por ejemplo, en-gb).
Se han introducido algunas mejoras en la implementación de la Voice API, como la eliminación de métodos obsoletos (por ejemplo, los setters de la clase com.vonage.client.voice.Call en lugar de utilizar el constructor que se añadió en la versión 7.3.0. Los dos cambios más importantes se han producido en VoiceClient.
En primer lugar, el método modifyCall junto con el método ModifyCallResponse. La implementación simplifica ahora las acciones de modificación de llamadas con llamadas directas a métodos. Por ejemplo, para finalizar (colgar) una llamada, utilice el método terminateCall(String) pasando sólo el ID de la llamada. Existen métodos similares para las demás acciones (earmuff / unearmuff, mute / unmute).
El otro cambio es en el método downloadRecording método Éste devolvía un objeto Recording con el que sólo se podían hacer dos cosas: obtener el contenido como un objeto InputStream o llamar al método save(Path) para almacenarlo en un archivo. La implementación de esto internamente no era bonita, así que se ha simplificado proporcionando dos nuevos métodos en VoiceClient: void saveRecording(String recordingUrl, Path destination) y byte[] downloadRecordingRaw(String recordingUrl). El primero, como su nombre indica, guardará la grabación desde la URL dada (recordingUrl) en el archivo deseado (destination). La segunda le proporcionará el contenido binario de la grabación (descargado de la URL recordingUrl) como una matriz de bytes, para que pueda decidir qué hacer con ella si no desea guardarla en un archivo. Por lo tanto, el método Recording downloadRecording(String recordingUrl) junto con la clase com.vonage.voice.client.Recording clase.
Por último, la PayAction NCCO junto con la clase PaymentPrompt ya no son compatibles con la API.
Además de eliminar código heredado para hacer frente a la deuda técnica, también hay algunas características nuevas que se describen a continuación. Si tienes curiosidad, el trabajo de refactorización interna para desacoplar las implementaciones de la API del cliente HTTP subyacente que comenzó en la versión 7.7.0 ya se ha completado, lo que allana el camino para actualizar el cliente en el futuro, por ejemplo, para permitir el soporte de peticiones asíncronas. Las pruebas también se han migrado a JUnit 5.
La versión 7.8.0 ha añadido la posibilidad de establecer un tiempo de espera personalizado para todas las solicitudes enviadas desde el SDK. Aunque nuestras API REST suelen responder con rapidez (medida en milisegundos en lugar de segundos), algunos puntos finales pueden tardar más en función de la cantidad de procesamiento necesario y de las condiciones de la red. Para aplicaciones sensibles al tiempo, puede ser útil establecer una fecha límite dura para las respuestas, de modo que no esté esperando más tiempo del necesario sin tener que crear hilos separados. Antes de la versión 7.8.0, el tiempo de espera por defecto dependía del sistema, ya que era el valor por defecto del cliente Apache HTTP subyacente (normalmente, 60 segundos). Ahora, puede configurarse al milisegundo más cercano usando el método HttpConfig.Builder#timeoutMillis(int) . Ahora también es de 60 segundos por defecto, independientemente de la configuración del sistema.
Se han añadido algunos campos adicionales para el flujo de trabajo Silent Auth en la API Verify v2. A saber, los campos sandbox y redirect_url en SilentAuthWorkflow, check_url en VerificationResponse. Nuestra documentación contiene más información sobre el flujo de trabajo síncrono de Silent Auth y Silent Auth sandbox si tiene curiosidad.
AccountClient Mejoras
La clase AccountClient del SDK de Java tiene puntos finales para las API de Pricing y Account. Sin embargo, faltaba el punto final precios salientes para todos los países para todos los países, que se ha añadido a partir de la versión 7.9.0. Este punto final, que puede invocarse con el método AccountClient#listPriceAllCountries(ServiceType) recupera información sobre precios de servicios para todos los países disponibles.
Además, se han añadido sobrecargas de métodos prácticos para la gestión de secretos. Ahora, si desea gestionar secretos para su Account principal (en contraposición a las subaccounts), no necesita proporcionar la clave API al método - ésta se derivará automáticamente del método de autenticación utilizado para construir el método VonageClient.
Al recibir webhooks de Vonage, se recomienda que verifiques la autenticidad de la carga útil validando la firma del token. Anteriormente, esto era un proceso manual, pero a partir de la versión 7.11.0, puedes utilizar el método de ayuda verifySignature(String jwt, String secret) en VoiceClient y MessagesClient. Esto simplemente delega en el nuevo método Jwt.verifySignature del artefacto com.vonage:jwt que se ha actualizado para admitir esta función. Ahora, ya no necesitas implementar la lógica para extraer y validar la firma de una carga útil entrante usando librerías de terceros - sólo necesitas proporcionar el JWT y el secreto compartido. El método devolverá true si el token fue firmado por el secreto dado.
Y estos son todos los cambios que debe conocer en la versión 8.0.0 del SDK de Java. Recuerde estar atento a las versiones bajo las coordenadas com.vonage:server-sdk para futuras actualizaciones. Si encuentra algún problema o tiene sugerencias de mejora, no dude en plantear un problema en GitHubo ponte en contacto con nosotros en Twitter o pásate por nuestro Slack de la comunidad. Espero que tengas una gran experiencia al usar las API de Vonage con la última versión del SDK de Java.
Compartir:
Sina es promotora de desarrollo Java en Vonage. Procede del mundo académico y, en general, siente curiosidad por todo lo relacionado con los coches, los ordenadores, la programación, la tecnología y la naturaleza humana. En su tiempo libre, se le puede encontrar paseando o jugando a videojuegos de competición.