Ao final do artigo criaremos uma aplicação standalone utilizando a JSR como exemplo prático. Com esta nova API o desenvolvedor poderá, rapidamente, produzir e consumir dados em JSON.
Sistemas de computadores geralmente não funcionam sozinhos, mas sim se integrando a outros sistemas, ora provendo, ora consumindo dados. Deste modo, os recursos envolvidos para viabilizar essa comunicação, como protocolo, APIs, formato de dados, etc. devem ser analisados quando projetamos qualquer aplicação.
Diante de tudo isso, é válido lembrar que, dependendo da solução, podemos aumentar ou reduzir a complexidade dessa interação.
Na plataforma Java EE é muito comum o uso do RMI, que é a base do EJB, para interoperabilidade entre componentes de uma mesma aplicação. Mas esse tipo de protocolo binário acaba sendo ineficiente como camada de integração entre softwares distintos, pois cria um acoplamento muito forte entre eles (devido à necessidade de exportar interfaces de serviços e DTOs – ver BOX 1 – para a aplicação cliente), além de permitir a integração apenas entre softwares que usam esta tecnologia.
DTO, sigla para Data Transfer Object, representa os objetos utilizados para transferir informações entre camadas da aplicação, ou entre aplicações distintas.
Já os protocolos baseados em texto, como o HTTP, permitem que criemos aplicações em qualquer tecnologia/linguagem para servir ou consumir serviços, além de deixar a comunicação mais compreensível para humanos, tornando mais fácil a depuração da troca de mensagens.
Com este cenário, os serviços web, apoiados no HTTP, vêm se consolidando como opção para integração de aplicações.
Até pouco tempo, o formato XML, aliado ao protocolo SOAP, era predominante no desenvolvimento de web services. O SOAP é uma excelente solução de integração, sendo um protocolo muito bem definido e consolidado. Porém, muitas vezes o excesso de padronização é visto como um obstáculo, pois faz com que a implementação seja mais trabalhosa.
É muito comum nos depararmos com problemas simples, e para solucioná-los também é comum estarmos dispostos a abrir mão de tanta padronização em benefício da agilidade. É neste ponto que serviços REST brilham, principalmente usando mensagens no formato JSON.
Nos últimos anos, a notação JSON vem se consolidando na preferência dos desenvolvedores como o formato ideal para se trabalhar com web services. Até a versão 6 da plataforma Java EE, no entanto, o Java não contava com uma API padrão para o processamento de JSON.
Deste modo, cada projeto utilizava uma implementação própria ou algumas conhecidas no mercado, como é o caso do Jackson. A JSR 353 vem para preencher esta lacuna, embarcando nos containers Java EE uma implementação padronizada para criação e leitura de conteúdo JSON.
Este artigo irá apresentar ao leitor a JSR 353 e como usá-la para ler e gerar conteúdos JSON através de duas técnicas conhecidas como modelo de objetos e modelo de streaming. Depois de apresentar a API, iremos construir um projeto de consulta de informações climáticas usando um serviço web público que retorna JSON, como um caso de uso prático da API.
JavaScript Object Notation – JSON
JSON vem sendo largamente adotado principalmente no desenvolvimento de serviços web. Grande parte deste crescimento se dá pela flexibilidade do formato e também pela facilidade de leitura por humanos. Ao contrário do XML, JSON é muito menos verboso, pois não possui o sistema de tags, é mais limpo e mais intuitivo.
Uma informação no formato JSON pode ser apresentada de duas maneiras: como um objeto simples ou como uma lista (array). Um objeto é uma sequência de pares chave/valor, semelhante a um mapa, sempre envolvida por chaves ({}). Na estrutura do par chave/valor, a chave é sempre uma String e o valor pode ser de seis tipos: uma String, um número (inteiro ou decimal), outro objeto, um array, true, false ou null.
Cada chave é separada do valor por dois pontos e os conjuntos chave/valor são separados entre si por vírgulas. Como o valor pode ser outro objeto, é possível formar uma estrutura hierárquica usando JSON.
Diferentemente do objeto, o array é envolvido por colchetes ([]) e seus elementos são separados por vírgula. Tais elementos não precisam ter a mesma estrutura ou ser do mesmo tipo.
Em consequência disso, podemos ter um array cujo primeiro elemento é um objeto JSON e o segundo elemento pode ser outro array. A Listagem 1 mostra um objeto JSON válido que contempla as possibilidades descritas.
Listagem 1. Exemplo de objeto JSON válido.
{
"editora" : "DevMedia",
"ano" : 2021,
"revista" : "Java Magazine",
"edicao" : 200,
"artigos" : [
{
"titulo" : "JEE21 – Criando um EJB com uma linha de código",
"caracteres" : 23000,
"revisado" : true,
"data" : "21/08/2021"
},
{
"titulo" : "JBrain Programming – Java com comando cerebral",
"caracteres" : 25000,
"revisado" : false,
"data" : null
}
],
"tiragem" : 120000
}JSR 353
De acordo com a especificação, a Java EE 7 provê “uma API para analisar, transformar e fazer consultas a dados JSON usando um modelo de objetos ou um modelo de streaming”. Na prática isso significa que a API nos oferece dois modelos para trabalhar com JSON, a saber:
· O modelo de objeto: Neste modelo, tanto na leitura quanto na criação de um objeto JSON a API ...
