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

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

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?

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.

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.

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.