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 v7.7.0
La versión 7.7.0 del Java SDK de Vonage ya está disponible. Esta publicación describe los cambios y qué esperar en el futuro cercano.
Entre marzo y agosto de 2023, ha habido siete versiones del SDK Java de Vonage con más de 35.000 líneas de cambios en el código desde la versión 7.1.1 de 2022. Como el esquema semántico de versiones sugiere, la actualización a la última versión debería ser compatible con versiones anteriores. Si utiliza una versión anterior a la 7.0.0, consulte el anuncio de la versión anuncio de la versión 7.0.0 para ver un resumen de los cambios. En este artículo, espero convencerte de que actualices a la última versión del SDK resumiendo las actualizaciones desde la v7.0.0.
Las principales novedades de las últimas versiones son las nuevas API que han pasado a la categoría de Disponibilidad General y, por tanto, son compatibles con nuestros SDK de servidor. Las siguientes API son ahora totalmente compatibles con el SDK de Java:
Verify v2: La nueva versión de Verify API añade canales adicionales, como WhatsApp (que incluso puede ser sin código), correo electrónico y voz, así como el tradicional SMS para implementar la autenticación multifactor en su aplicación. Además, los flujos de trabajo de verificación ahora tienen fallbacks, por lo que puede añadir un tiempo de espera para cada canal y probar un método de autenticación diferente o un número de teléfono de contacto como copia de seguridad.
Reuniones: Solución de bajo código que permite crear y gestionar salas de reuniones de forma dinámica. Si alguna vez has utilizado Vonage Business Cloudesta API te permite programar y personalizar la aplicación VBC según las necesidades de tu organización.
Subaccounts: Esta API le permite crear y gestionar Subaccounts, que pueden ser útiles para separar y realizar un seguimiento del uso, la facturación y los números asignados según la unidad de negocio o el departamento. Tenga en cuenta que esto requiere que la función esté habilitada en su Account.
Además de las nuevas API, las mejoras más notables afectan a la Messages API. Desde la versión 7.1.0, se puede utilizar el Mensajes API Sandbox del SDK de Java, que te permite probar el envío de mensajes a través de WhatsApp, Viber y Facebook Messenger sin tener que configurar una cuenta de empresa en cada una de esas plataformas. Ya están disponibles nuevos tipos de mensajes:
Estos tipos de mensaje dedicados para WhatsApp facilitan el envío declarativo de ubicaciones, stickers y productos sin tener que construir un tipo de mensaje personalizado. Por supuesto, la API de WhatsApp es muy completa y puede seguir utilizando tipos de mensaje personalizados, por ejemplo, para enviar un contacto.
Ahora también puedes incluir botones de acción en tus mensajes de texto e imagen de Viber. Otra adición notable es un mejor soporte para mensajes entrantes. El Messages API no sólo sirve para enviar mensajes, sino también para recibirlos. Esto se hace a través de webhooks. Al configurar un receptor de mensajes entrantes, los datos enviados a su servidor de aplicaciones (como se describe en la especificación de la API) se pueden deserializar en un objeto com.vonage.client.messages.InboundMessage objeto. Lo mismo ocurre con webhook de estado de mensajeque puede deserializarse mediante la clase com.vonage.client.messages.MessageStatus clase. Si ya utiliza webhooks para inspeccionar el estado de los mensajes, le alegrará saber que se ha corregido la deserialización de las marcas de tiempo.
La implementación del SDK de la API de aplicaciones se ha actualizado con documentación mejorada y se han añadido los campos que faltaban. En particular, se han actualizado las funciones de Voice con los campos conversations_ttl, signed_callbacksy region . Ahora puede configurar los campos connection_timeout y socket_timeout en Webhook - que ahora tiene un Constructor para facilitar la construcción. El fallback_answer_url tipo webhook también se ha añadido. Para mayor comodidad, ahora puede listar fácilmente todas las aplicaciones utilizando el nuevo ApplicationClient::listAllApplications() método. En aras de la uniformidad, cualquier respuesta de error 4xx o 500 de la API se incluirá ahora en un campo ApplicationResponseException al igual que con nuestras otras nuevas API, para que pueda inspeccionar e investigar más fácilmente los detalles del error.
Dado que los usuarios están vinculados a una aplicación concreta, recientemente hemos añadido puntos finales de gestión de usuarios a la API de Aplicaciones. La API en sí es bastante sencilla, ya que proporciona operaciones CRUD para gestionar usuarios en tus Applications. En la actualidad, las utiliza la Conversation API (API de conversación).. Un usuario puede tener asociados varios canales de contacto: SMS, WhatsApp, Viber, Facebook Messenger, PSTN, SIP, VBC y Websocket. El SDK de Java admite la gestión de usuarios a través del nuevo paquete com.vonage.client.users paquete.
La implementación de la Voice API (com.vonage.client.voice.*) también ha recibido algunos cambios notables. Esto incluye pequeñas correcciones como la serialización de un campo (específicamente, randomFromNumber en Call) y la deserialización del tipo app tipo endpoint.
El mayor cambio, sin embargo, es la tendencia a utilizar el patrón Builder para construir objetos. Esto está más alineado con la forma en que otras APIs manejan la construcción de cuerpos de solicitud. En particular, la creación de una llamada (mediante el método VoiceClient#createCall(Call) ) debería ser más sencilla y declarativa, ya que el objeto Call tiene ahora un Builder que puedes usar para establecer las propiedades de la llamada, en lugar de intentar recordar cuál de los muchos constructores usar. También simplifica la adición de nuevos parámetros y características para las propiedades iniciales de la llamada. Otra clase que ha recibido el tratamiento Builder es TalkPayload (como se utiliza en VoiceClient#startTalk). Se aplica la misma idea: en lugar de tratar de encontrar la firma del método con la combinación deseada de parámetros, ahora puede llamar a VoiceClient#startTalk(String uuid, TalkPayload properties) usando TalkPayload.builder() para definir las propiedades de interés.
En consecuencia, las demás variantes de startTalk han quedado obsoletas y se eliminarán en la próxima versión principal. Hablando de esto, los setters de la clase Call también han quedado obsoletos en favor del uso de Builder. Para ordenar aún más las cosas, algunas clases internas se han hecho paquete privado, y los que potencialmente podría ser utilizado (CallModifier y ModifyCallPayload) han quedado obsoletas.
Además de correcciones y refactorizaciones, también hay nuevas funciones. Lo más destacable es Detección avanzada de máquinas (que puede configurarse mediante el método Call.Builder#advancedMachineDetection ). Si se especifica, esta función anula la función estándar de detección de máquinas. Es mucho más precisa a la hora de detectar el buzón de voz y es una función premium, por lo que se cobrará por llamada. Otra nueva función es Texto a voz Premiumque puede seleccionarse configurando TalkPayload.Builder#premium(boolean) en true. También está disponible en el TalkAction NCCO. Estas voces premium suenan más naturales y se tarifican en función del número de caracteres. Consulte nuestra documentación para desarrolladores la lista de idiomas compatibles.
Por último, se han realizado un par de añadidos que faltaban en la implementación de la API en el SDK. Se ha añadido la posibilidad de ajustar el nivel de volumen del texto a voz en TalkPayload (disponible a través del Builder). Puede ajustarse en un rango de -1 a 1, siendo 0 el valor predeterminado, -1 el más bajo y 1 el más alto. El punto final VBC también se ha añadido al SDK.
Si está actualizando desde la versión 7.0.0 o anterior, se han introducido algunas mejoras de calidad en la API Verify v1 clásica. Aunque animamos a los usuarios a migrar a la nueva Verify v2 API, el SDK sigue siendo compatible con la Verify API clásica. La última versión del SDK de Java está ahora más alineada con la especificación. En particular, se han añadido los campos que faltaban, ahora se admite Bring Your Own PIN y se han eliminado los campos que no se utilizaban.
Por supuesto, una de las ventajas de actualizar a la última versión del SDK es la seguridad. Aunque el SDK de Java tiene relativamente pocas dependencias, las principales -Jackson y Apache HTTP Client- son especialmente susceptibles de CVE, por lo que es importante mantenerlas actualizadas. Antes de cada lanzamiento del SDK de Java, se comprueba la versión de cada dependencia para asegurarse de que es la última versión menor o parche disponible. Dicho esto, eliminar las dependencias que no son necesarias para reducir el riesgo de vulnerabilidades de seguridad también es una buena práctica.
En versiones recientes, javax.servlet y javax.xml.bind se han eliminado ya que el SDK no las necesitaba. Por compatibilidad, la dependencia jakarta.servlet (que sustituye a javax.servlet) es opcional pero, en teoría, nunca debería ser necesaria. Algunas clases internas tienen una dependencia implícita de javax.servlet.HttpServletRequest. Sin embargo, se han dejado obsoletas, de modo que la dependencia puede eliminarse por completo. En particular, si utiliza com.vonage.client.sms.callback.AbstractMOServletha quedado obsoleto y se eliminará en la próxima versión principal.
Lo más probable es que el próximo gran cambio en el SDK sea la actualización de Apache HTTP Client 4 a 5. Antes de que eso ocurra, es necesario realizar una importante refactorización interna. Actualmente, cada subcliente (es decir, los clientes utilizados para cada API, VoiceClient) está compuesto por múltiples endpoints. Se trata de clases internas que gestionan la lógica de enviar la solicitud al punto final de API correcto y devolver la respuesta deserializada. Esta lógica está estrechamente vinculada a la implementación del cliente HTTP subyacente, lo que hace que la migración a un cliente diferente sea muy difícil. Actualmente estoy trabajando en desacoplar la implementación de estos puntos finales, lo que también debería reducir la repetición de tareas. En la versión 7.7.0 se han hecho algunos progresos y se han migrado varias API a este nuevo enfoque. Por lo tanto, es posible que observe algunas nuevas interfaces públicas como Jsonable y QueryParamsRequest en algunos objetos de dominio.
Una vez que este trabajo esté hecho para todas las APIs soportadas por el SDK, la migración será mucho más sencilla, ya que habrá un único lugar para cambiar la lógica subyacente en lugar de cada punto final de la API (¡y no nos olvidemos de las pruebas!) en el SDK. Entonces estaremos en condiciones de migrar a Apache HttpClient 5. Esto será bueno no sólo para la seguridad, sino que también sienta las bases para una de las características más solicitadas: peticiones no bloqueantes (asíncronas).
Eso es todo por ahora. Si te encuentras con algún problema o tienes sugerencias de mejora, no dudes 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.