Compartilhar:
){kind=small}
Sina é um ex-membro da equipe da Vonage. Ele atuou como Java Developer Advocate na Vonage. Com formação acadêmica, ele tem uma curiosidade geral por tudo o que se relaciona a carros, computadores, programação, tecnologia e natureza humana. Em seu tempo livre, ele gosta de caminhar ou jogar videogames competitivos.
Anunciando o SDK Java da Vonage v7.7.0
A versão 7.7.0 do SDK Java da Vonage já está disponível! Esta publicação descreve as mudanças e o que podemos esperar no futuro próximo.
Entre março e agosto de 2023, houve sete lançamentos do SDK Java da Vonage, com mais de 35 mil linhas de alterações no código desde a versão v7.1.1 de 2022. Conforme o esquema de versionamento semântico sugere, a atualização para a versão mais recente deve ser compatível com versões anteriores. Se você estiver usando uma versão anterior à 7.0.0, consulte a postagem de anúncio da v7.0.0 para obter um resumo das alterações. Neste artigo, espero convencê-lo a atualizar para a versão mais recente do SDK, resumindo as atualizações desde a v7.0.0.
A principal novidade das versões recentes são as novas APIs que passaram para o status de Disponibilidade Geral e, portanto, agora são compatíveis com nossos SDKs de servidor. As seguintes APIs agora são totalmente compatíveis com o SDK Java:
Verify v2: A nova versão da Verify API adiciona canais extras, como o WhatsApp (que pode até ser usado sem código), e-mail e voz, além do tradicional SMS, para implementar a autenticação multifatorial em seu aplicativo. Além disso, os fluxos de trabalho de verificação agora contam com planos alternativos, permitindo que você defina um tempo limite para cada canal e tente um método de autenticação diferente ou um número de telefone alternativo como plano de contingência.
Reuniões: Solução de baixo código que permite criar e gerenciar salas de reunião de forma dinâmica. Se você já usou Vonage Business Cloud, esta API permite que você provisionar e personalizar programaticamente o aplicativo VBC de acordo com as necessidades da sua organização.
Subaccounts: Esta API permite que você crie e gerencie Subaccounts, o que pode ser útil para separar e acompanhar o uso, o faturamento e os Numbers atribuídos de acordo com a unidade de negócios ou departamento. Observe que, para isso, é necessário que o recurso esteja habilitado na sua conta.
Além das novas APIs, as melhorias mais notáveis dizem respeito à Messages API. A partir da versão 7.1.0, agora é possível usar a Sandbox da Messages API do SDK do Java, o que permite testar o envio de mensagens pelo WhatsApp, Viber e Facebook Messenger sem precisar configurar um Account comercial em cada uma dessas plataformas. Agora, novos tipos de mensagem estão disponíveis:
Esses tipos de mensagem específicos do WhatsApp facilitam o envio declarativo de localizações, adesivos e produtos, sem a necessidade de criar um tipo de mensagem personalizado. É claro que a API do WhatsApp é abrangente, e você ainda pode usar tipos de mensagem personalizados — por exemplo, para enviar um contato.
Agora você também pode incluir botões de ação em suas mensagens de texto e imagem no Viber. Outra novidade digna de destaque é o melhor suporte para mensagens recebidas. A Messages API não serve apenas para enviar mensagens, mas também para recebê-las. Isso é feito por meio de webhooks. Ao configurar um ouvinte para mensagens recebidas, os dados enviados ao servidor do seu aplicativo (conforme descrito na especificação da API) podem agora ser deserializados em um com.vonage.client.messages.InboundMessage objeto. O mesmo se aplica ao webhook de status da mensagem, que pode ser deserializado por meio da com.vonage.client.messages.MessageStatus classe. Se você já utiliza webhooks para verificar o status das mensagens, ficará satisfeito em saber que a deserialização dos carimbos de data/hora já foi corrigida.
A implementação do SDK da API de aplicativos foi atualizada com documentação aprimorada e campos que estavam faltando foram adicionados. Em particular, os recursos de Voice foram atualizados com o conversations_ttl, signed_callbacks, e region . Agora é possível definir o connection_timeout e socket_timeout em Webhook — que agora conta com um Construtor para facilitar a criação. O fallback_answer_url tipo de webhook também foi adicionado. Para maior conveniência, agora você pode listar facilmente todos os Applications usando o novo ApplicationClient::listAllApplications() método. Para uniformidade, quaisquer respostas de erro 4xx ou 500 da API agora serão envolvidas em um ApplicationResponseException , assim como em nossas outras novas APIs, para que você possa inspecionar e investigar mais facilmente os detalhes do erro.
Como os usuários estão vinculados a uma aplicação específica, adicionamos recentemente pontos de extremidade de gerenciamento de usuários à API de Applications. A API em si é bastante simples, oferecendo operações CRUD para gerenciar usuários em suas Applications. Atualmente, elas são utilizadas pela Conversation API. Um usuário pode ter vários canais de contato associados a ele — como SMS, WhatsApp, Viber, Facebook Messenger, PSTN, SIP, VBC e Websocket. O SDK Java oferece suporte ao gerenciamento de usuários por meio do pacote recém-adicionado com.vonage.client.users .
A implementação da Voice API (com.vonage.client.voice.*) também recebeu algumas alterações notáveis. Isso inclui pequenas correções, como a serialização de um campo (especificamente, randomFromNumber em Call) e a desserialização do app tipo de endpoint.
A maior mudança, no entanto, é a adoção do padrão Builder para a construção de objetos. Isso está mais alinhado com a forma como outras APIs lidam com a construção de corpos de solicitação. Em particular, a criação de uma chamada (por meio do VoiceClient#createCall(Call) método) deve agora ser mais simples e mais declarativa, já que o Call objeto agora possui um Builder que você pode usar para definir as propriedades da chamada, em vez de tentar lembrar qual dos muitos construtores usar. Isso também simplifica a adição de novos parâmetros e recursos para as propriedades iniciais da chamada. Outra classe que recebeu o tratamento Builder é TalkPayload (conforme usada em VoiceClient#startTalk). A mesma ideia se aplica: em vez de tentar encontrar a assinatura do método com a combinação desejada de parâmetros, agora você pode chamar VoiceClient#startTalk(String uuid, TalkPayload properties) usando TalkPayload.builder() para definir as propriedades de seu interesse.
Consequentemente, as outras variantes de startTalk foram consideradas obsoletas e serão removidas na próxima versão principal. Por falar nisso, os setters da Call classe também foram marcados como obsoletos, em favor do uso do Builder. Para organizar ainda mais as coisas, algumas classes internas foram tornadas privadas ao pacote, e aquelas que poderiam ser potencialmente utilizadas (CallModifier e ModifyCallPayload) foram consideradas obsoletas.
Além das correções e da refatoração, há também novas funcionalidades. A mais notável é Detecção Avançada de Máquinas (que pode ser configurada usando o Call.Builder#advancedMachineDetection método). Se especificado, esse recurso substitui o recurso padrão de detecção de aparelho. Ele é significativamente mais preciso na detecção de correio de voz e é um recurso premium, portanto, será cobrado por chamada. Outro novo recurso é o Texto-para-Fala Premium, que pode ser selecionado definindo TalkPayload.Builder#premium(boolean) para true. Esse recurso também está disponível no TalkAction NCCO Builder. Essas vozes premium soam mais naturais e são cobradas com base no número de caracteres. Consulte nossa documentação para desenvolvedores para obter uma lista dos idiomas suportados.
Por fim, foram feitas algumas adições que estavam faltando na implementação da API no SDK. A possibilidade de ajustar o nível de volume da função “Text-to-Speech” foi adicionada a TalkPayload (disponível por meio do Builder). Esse valor pode ser definido em uma faixa de -1 a 1, sendo 0 o padrão, -1 o mais baixo e 1 o mais alto. O ponto de extremidade VBC também foi adicionado ao SDK.
Se você estiver atualizando a partir da versão 7.0.0 ou anterior, houve algumas melhorias de usabilidade na API clássica do Verify v1. Embora incentivemos os usuários a migrarem para a nova API do Verify v2, o SDK ainda oferece suporte à Verify API. A versão mais recente do SDK para Java está agora mais alinhada com a especificação. Notavelmente, campos que estavam faltando foram adicionados, o recurso “Bring Your Own PIN” agora é suportado e campos não utilizados foram descontinuados.
É claro que um dos benefícios de atualizar para a versão mais recente do SDK é a segurança. Embora o Java SDK tenha relativamente poucas dependências, as principais — Jackson e Apache HTTP Client — são particularmente suscetíveis a CVEs; portanto, é importante mantê-las atualizadas. Antes de cada lançamento do SDK do Java, todas as versões das dependências são verificadas para garantir que sejam as versões menores ou de correção mais recentes disponíveis. Dito isso, remover dependências desnecessárias para reduzir o risco de vulnerabilidades de segurança também é uma boa prática.
Nas versões mais recentes, javax.servlet e javax.xml.bind as dependências foram removidas, já que o SDK não precisava delas. Por motivos de compatibilidade, a jakarta.servlet dependência (que substitui javax.servlet) é opcional, mas, em teoria, nunca deveria ser necessária. Algumas classes internas têm uma dependência implícita de javax.servlet.HttpServletRequest. No entanto, essas classes foram marcadas como obsoletas para que a dependência possa ser removida por completo. Em particular, se você estiver usando com.vonage.client.sms.callback.AbstractMOServlet, ela agora foi considerada obsoleta e será removida na próxima versão principal.
A próxima grande mudança no Client SDK provavelmente será uma atualização do Apache HTTP Client da versão 4 para a 5. Antes que isso possa acontecer, é necessária uma refatoração interna significativa. Atualmente, cada subcliente (ou seja, os clientes usados para cada API, por exemplo, VoiceClient) é composto por vários endpoints. Trata-se de classes internas que lidam com a lógica de enviar sua solicitação ao endpoint correto da API e retornar a resposta deserializada. Essa lógica está fortemente acoplada à implementação do cliente HTTP subjacente, o que torna a migração para um cliente diferente muito difícil. No momento, estou trabalhando para desacoplar a implementação desses endpoints, o que também deve reduzir o código repetitivo. Houve algum avanço na versão 7.7.0, com várias APIs migradas para essa nova abordagem. Portanto, você poderá notar algumas novas interfaces voltadas para o público, como Jsonable e QueryParamsRequest em alguns objetos de domínio.
Assim que esse trabalho for concluído para todas as APIs compatíveis com o SDK, a migração ficará muito mais simples, pois haverá um único local para alterar a lógica subjacente, em vez de precisar fazer isso em cada endpoint de API (e não podemos esquecer dos testes!) no SDK. Estaremos então prontos para migrar para o Apache HttpClient 5. Isso será benéfico não apenas para a segurança, mas também estabelecerá as bases para um dos recursos mais solicitados: solicitações não bloqueantes (assíncronas).
Por enquanto é só isso! Se você encontrar algum problema ou tiver sugestões de melhorias, fique à vontade para abrir um ticket no GitHubou entre em contato conosco no Twitter ou dar uma passada no nosso Slack da Comunidade. Espero que você tenha uma ótima experiência ao usar as APIs da Vonage com a versão mais recente do SDK para Java!
Compartilhar:
Sina é um ex-membro da equipe da Vonage. Ele atuou como Java Developer Advocate na Vonage. Com formação acadêmica, ele tem uma curiosidade geral por tudo o que se relaciona a carros, computadores, programação, tecnologia e natureza humana. Em seu tempo livre, ele gosta de caminhar ou jogar videogames competitivos.