Há um sistema aqui onde trabalho que irá fornecer tipos para outros sistemas. São vários tipos, essencialmente, são classes com um identificador e descrição. E cada tipo, representa uma tabela no banco.
A forma escolhida para integração foi via serviços Rest. Contudo, a forma que está sendo conduzida, me chama atenção: Para cada tabela de tipo, há um classe, uma entidade para representar este tipo. E para trafegar via JSON, nos provimentos dos serviços, foram criados VO’s para cada entidade. E obrigatoriamente, estes VO’s são duplicados(Ctrl+C e Ctrl+V) nos sistemas que consomem estes serviços.
Os projetos aqui, rodam em cima do maven, sugeri a criação de um módulo de VO’s que pudesse ser exportado, contudo, solução foi refutada.
A minha pergunta é: existe uma abordagem melhor? Pois, este tipo de integração não possui quase reaproveitamento nenhum.
um modulo de VOs tem cara de ser um jar “cliente” que vai saber integrar e vai saber como deserializar os dados, como conectar, etc.
eu nao entendo pq alguem rejeitaria isso. por outro lado dizer que não tem reaproveitamento é um comentario muito forte. REST possui menos overhead porem cada cliente precisa saber como é o recurso para poder acessa-lo.
se vc nao pode expor um .jar com os VOs, existe a opção de vc tentar gerar codigo a partir de alguma coisa, como uma linguagem de descrição / IDL
algumas pessoas ja me falaram do http://piqi.org/ porem eu nao sei como é na pratica. porem qq coisa q use reflection ou que gere codigo pode ser tão ou mais complicado do que um simples RestClient.versao2.99.jar no classpath que faz todo o meio de campo.
perceba que a integração de tipos é feita com base em uma especificação: se vc vai copiar codigo ou usar algo em comum é a sua estrategia pra reaproveitamento. isso não tem nada haver com o tipo de integração. qualquer integração tem exatamente esse problema. quando vc usa SOAP e cria os stubs a partir do wsdl é a mesma coisa que copiar um VO.
Seu modulo VO só vai funcionar para clientes Java. Isso é acoplamento.
Mas o acoplamento é menor com SOAP, porque você pode gerar stubs pra clientes em diversas linguagens, em tempo de compilação.
E o acoplamento é ainda menor com REST, porque você não precisa gerar nada. Um cliente pode descobrir como acessar o seu serviço, em tempo de execução e usando qualquer linguagem.
Então, neste cenário de Rest, cada sistema que consumisse o serviço seria o responsável por tratar as respostas.
Contudo, ainda tenho uma dúvida: pensando em um universo pequeno, poucas aplicações internas. Estes serviços não sendo expostos a outras linguagens. É difícil alcançar nenhum acoplamento, neste cenário acima, acoplar com um modelo SOAP seria uma boa opção? Haveria outras formas além daquele Jar?
o fato de vc oferecer um client em uma dada linguagem como uma referencia de implementação não anula que a integração é feita via REST.
um exemplo: o Riak é um banco de dados NoSQL e tem uma interface REST e oferece uma biblioteca pra vc utilizar essa interface ( e a ProtoBuf tb ) em diversas linguas. isso diminui o tempo de implementação.
outro exemplo: Google Drive tem uma API REST e tem um cliente java ( e python também se não me engano). deixou de ser REST?
REST diz respeito a como vc expoe os seus recursos, suas transformações, etc. se vc tem 3 projetos que precisam integrar via REST, todos em java, todos dentro da mesma empresa, qual a razão pra que cada projeto gere os artefatos necessarios para conectar com a API? pra que ter 3x mais desenvolvimento? até pq estamos falando que algo que vai
serializar objetos em xml/json/yml/etc
enviar via http
traduzir a resposta
de-serializar os objetos
“ah cria acoplamento”. qq coisa cria acoplamento. se vc precisar usar OAuth vai ter o acoplamento das bibliotecas para usar OAuth.
Discordo em parte. HTTP é o mecanismo de transporte vc ainda precisa serializar/de-serializar os dados (fora outras coisas como OAuth).
Se um projeto precisa acessar apenas um serviço ( de 90 ) talvez valha a pena fazer algo bem simples e focado, algo que só faça GET /coisas talvez vc só precise de algo q te permite fazer isso via HTTP.
As formas que conheço são essas, JAR, SOAP, HATEOS, do mais acoplado para menos.
A medida de acoplamento se dá pela necessidade de recompilar o cliente caso o servico mude. imagina se todo mundo tiver que recompilar seu browser pra acessar a nova versão do GUJ? Não rola, por isso o GUJ é mais RESTful que um sistema SOAP, ou um sistema que precisa de um JAR no cliente.
Curiosamente ninguem diz que websites são sistemas REST, apesar de essa ser a arquitetura usada na web. Mas quando uma grande empresa cria uma API HTTP ela é automaticamente considerada REST por alguns.
Do que você esta falando? Certamente não é REST, que não precisa gerar artefato nenhum para o cliente conseguir conectar. Desculpa, mas isso é básico sobre sistemas REST.
Por favor, me aponte para uma documentação oficial do RIAK falando em API REST.
OAuth não tem nenhum relação com REST, portanto é irrelevante dizer que para usar OAuth precisa de bibliotecas. Por acaso está dizendo que não existem arquiteturas que promovem baixo acoplamento? Pois volto a citar o exemplo do GUJ que atualizou o sistema web e ninguém precisou recompilar o browser.
Sério? Eu nunca precisei serializar/deserializar nada na minha aplicação cliente. Por que eu precisaria, HTTP é apenas texto.
