Criação de clientes Java para os serviços REST
Expusemos com bom nível de detalhe a implementação de serviços REST do lado do servidor. Para permitir uma visão completa da comunicação, é muito importante falar também de clientes RESTful.
Uma vez que já temos o protocolo estabelecido, o papel do cliente é manipular as solicitações e respostas no formato acordado com o servidor. Para exemplificar como pode ser feito isso do lado do cliente, apresentamos na listagem abaixo a classe OfertaTestREST, que realiza uma solicitação para cadastro de uma oferta sobre um item. O código deste teste foi feito para facilitar a ilustração do que está sendo feito. Este é o motivo de imprimir os cabeçalhos e corpo tanto da requisição como da resposta HTTP.
public class OfertaTestREST extends TestCase { public void testCadastro() throws HttpException, IOException{ // Criamos o usuário Usuario usuario = new Usuario(); usuario.setNome("Usuario Artigo"); usuario.setEmail("usuario@test.com"); usuario.setLogin("artigo" + System.currentTimeMillis()); UsuarioService usuarioService = ServiceFactory.getUsuarioService(); usuario = usuarioService.cadastrar(usuario); // Criamos o item Item item = new Item(); item.setDescricao("Item teste Artigo " + System.currentTimeMillis()); item.setNome("Iphone"); item.setNovo(true); item.setValorInicial(new BigDecimal(0)); item.setVendido(false); ItemService itemService = ServiceFactory.getItemService(); item = itemService.cadastrar(item, usuario); // E agora a criação da Oferta de maneira RESTFul Oferta oferta = new Oferta(); oferta.setDataModificacao(new Date()); oferta.setItem(item); oferta.setOfertante(usuario); oferta.setValor(new BigDecimal(111.22).setScale(2, RoundingMode.HALF_UP)); // Montando requisição com o commons-http-client HttpClient client = new HttpClient(); PostMethod method = new PostMethod("http://localhost:8080/item/" + item.getCodItem() + "/ofertas"); // Geração de XMLs com o XStream XStream xstream = new XStream(); xstream.alias("oferta", Oferta.class); xstream.alias("ofertante", Usuario.class); xstream.alias("item", Item.class); String ofertaXml = xstream.toXML(oferta); System.out.println(ofertaXml); // Definindo corpo da requisição StringRequestEntity requestEntity = new StringRequestEntity(ofertaXml, "text/xml", "UTF-8"); method.setRequestEntity(requestEntity); // Here it goes... int statusCode = client.executeMethod(method); // Status HTTP deve ser 201 - Created assertEquals(HttpServletResponse.SC_CREATED, statusCode); System.out.println("\n#### REQUISIÇÃO ####\n"); System.out.println(method.getName() + " " + method.getPath()); Header[] headersRequest = method.getRequestHeaders(); for(Header header : headersRequest){ System.out.println(header.getName() + " : " + header.getValue()); } method.getRequestEntity().writeRequest(System.out); System.out.println("\n\n#### RESPOSTA ####\n"); System.out.println(method.getStatusLine().getHttpVersion() + " " + method.getStatusLine().getStatusCode()); Header[] headersResponse = method.getResponseHeaders(); for(Header header : headersResponse){ System.out.println(header.getName() + " : " + header.getValue()); } System.out.println(method.getResponseBodyAsString()); } }
O formato da requisição HTTP gerada por esta classe pode ser visto na primeira listagem abaixo. Na listagem seguinte pode ser conferido o formato da resposta HTTP a esta solicitação. A terceira listagem desta sequência mostra o formato da resposta à busca de ofertas de um determinado item.
#### REQUISIÇÃO #### POST /item/13c017ba-7c01-44aa-9a0b-b815a9ea298f/ofertas User-Agent : Jakarta Commons-HttpClient/3.0.1 Host : localhost:8080 Content-Length : 596 Content-Type : text/xml; charset=UTF-8 <oferta> <valor>111.22</valor> <dataModificacao>2008-09-28 10:36:54.642 BRT</dataModificacao> <item> <codItem>13c017ba-7c01-44aa-9a0b-b815a9ea298f</codItem> <nome>Iphone</nome> <descricao>Item teste Tech Talk 1222609014628</descricao> <valorInicial>0</valorInicial> <novo>true</novo> <vendido>false</vendido> </item> <ofertante> <codUsuario>fc6104ad-b9a5-4b2d-9085-a186083b9c2d</codUsuario> <nome>Usuario Tech Talk</nome> <login>techtalk1222609014475</login> <email>usuario@test.com</email> </ofertante> <vencedora>false</vencedora> </oferta>
#### RESPOSTA #### HTTP/1.1 201 Server : Apache-Coyote/1.1 Location : http://localhost:8080/item/13c017ba-7c01-44aa-9a0b-b815a9ea298f/ofertas Content-Length : 0 Date : Sun, 28 Sep 2008 13:36:55 GMT
A implementação das solicitações HTTP em Java pode ser feita com uso da biblioteca commons-http-client. Esta API permite que montemos requisições HTTP e recebamos suas respostas correspondentes, da mesma forma que ocorreria com um browser simples. Não existe a capacidade de executar código javascript e também não existem equivalentes para os plugins dos browsers completos. Mesmo sem estes recursos, o commons-http-client nos dá o poder de fazer praticamente qualquer operação padrão HTTP do lado cliente. Isto torna esta biblioteca um componente de fundamental importância para implementações RESTful feitas em Java.
Conteúdo muito bom, mas me chamou a atenção o uso do XStream. O JAXB já está instalado na máquina do cliente, portanto usar XStream me parece adicionar uma dependência sem ganho aparente em desempenho ou qualidade da solução.
Se eu puder sugerir uma melhoria, sugiro o JAXB no lugar o XStream, reduzindo o número de dependências do projeto.
Outro detalhe que senti falta foi o XSD Schema do meta-dado e a validação do XML de entrada e saída das operações… Mesmo considerando que temos o controle nas duas pontas (cliente e servidor), a validação é sempre recomendada, e melhor ainda se a validação incluir handlers para a validação de regras negócios – o que existe por default no JAXB.
esta linha, por exemplo: oferta.setValor(new BigDecimal(111.22).setScale(2, RoundingMode.HALF_UP));
sugere que o valor esperado pelo servidor tem duas casas decimais e é do tipo “xsd:long”, mas no código cliente apresentado fica impossível detectar isso.. além disso, se o contrato (WADL) no servidor for alterado, alguém terá de atualizar esta linha de código e nem sempre isso é de fácil detecção no caso de meta-dados com muitos atributos.
Oi Felipe, ótimas observações mesmo. Sobre o uso do JAXB x XStream, eu normalmente uso o JAXB quando posso usar JDK 1.5 e XStream para JDK 1.4/1.3. O JAXB 2.0 exige JDK 1.5, o que infelizmente só está disponível em parte das aplicações lá no trabalho.
Sobre as validações dos XMLs, não fazemos por XML Schema como é feito em SOAP. Como temos o server e fornecemos o client para as aplicações, o client sempre “confia” que os dados do servidor são válidos.
Já o servidor valida todos os dados enviados pelos clientes, e retorna as mensagens de erro detalhadas. Atualmente fazemos essas validações com o Hibernate Validator, mas não tem nenhum motivo especial para isso ter sido feito com ele não. Foi questão só de familiaridade mesmo.
Outra coisa, eu pretendo escrever outros artigos especificamente de JAXB e XStream, só que resolvi publicar esse artigo mesmo ainda não tendo os outros. Daqui a algumas semanas pretendo adicionar esses outros, aí fica mais completo
Fala Bruno,
Primeiramente queria parabenizar ai pelo artigo e dizer que tem gente aqui em SC que aprecia o teu trabalho =)
Bom, eu também trabalho com integração de sistemas e ao meu ver o ponto fraco do REST seria essa falta de validação das mensagens de emtrada, como falou o Felipe Gaucho. Quando você trabalha com integração entre 2 sistemas que foi você quem fez ambos, você realmente pode “confiar” que os dados vão chegar corretamente. Mas na vida real nem sempre acontece desta maneira, e nos deparamos com situações em que essa validação é realmente necessária. Minha pergunta, esta validação é contra os princípios do REST, pois pode acabar tendo toda a burocracia dos padrões WS-*, ou ela pode ser feita sem problemas?
@Gabriel
Fico feliz de saber que tem gente de SC que me conhece, e saiba que eu tenho muita vontade de conhecer sua terra
A respeito das validações, você pode validar tanto quanto julgar necessário. Caso você tenha controle sobre todas as aplicações que se comunicam, você pode validar um pouco menos se quiser, mas isto é totalmente decisão sua.
Normalmente em serviços SOAP, sua pilha de web services fará automaticamente a validação dos dados enviados, comparando-os com os schemas XML declarados no WSDL. Quase sempre este é o padrão, então se você estiver usando SOAP, você provavelmente já terá “de graça” a validação dos schemas XML. As validações de regras de negócio serão feitas dentro da implementação dos web services, e este tipo de validação pode ser feito de qualquer forma que você queira.
Em termos de validações, com REST você PODE fazer todas as validações feitas em serviços WS-*, e validar muito mais coisa. Isto não é especificado e não é nem contra nem a favor de nenhum princípio de REST. A diferença é que você não é OBRIGADO a validar nada, e nem mesmo OBRIGADO a ter schemas XML. O correto é analisar os requisitos e utilizar o nível de formalidade que for mais coerente para a situação.
[]s
Bruno,
Essa classe que ele extende de TestCase é o que? Um JUnit?
Bruno muito obrigado por compartilhar essas informações conosco, eu estava precisando realização um conexão com servidor rest com uma aplicação usado java 1.4 e seu foi essensial no termino do meu trabalho….
Muito obrigado.