Bruno Pereira

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());
}
}

#### 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

7 Responses to “WebServicesREST - Criação de clientes Java para os serviços REST”

1. Felipe Gaúcho Says:
   September 29th, 2008 at 8:08 am

   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.

2. Felipe Gaúcho Says:
   September 29th, 2008 at 8:10 am

   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.

3. blpsilva Says:
   September 29th, 2008 at 8:33 am

   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.

4. blpsilva Says:
   September 29th, 2008 at 8:34 am

   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

5. Gabriel Says:
   November 5th, 2008 at 8:49 pm

   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?

6. blpsilva Says:
   November 5th, 2008 at 9:04 pm

   @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

7. Roan Says:
   September 24th, 2009 at 3:49 pm

   Bruno,

   Essa classe que ele extende de TestCase é o que? Um JUnit?

Leave a Reply