Serviços REST - Integração de tipos

Ola

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.

Obrigado pelas pontuações.

De certa forma, acaba dando no mesmo. Havendo esse “contrato”, tudo acaba muito parecido.

hm? Se o cliente tem que usar um jar pra conectar no seu serviço, você está criando acoplamento, e não reaproveitando.

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.

Você pode até acoplar o seu sistema dessa maneira, mas não é REST.

Se for um sistema REST, você só precisa de uma biblioteca HTTP no cliente.

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?

Mais uma vez Obrigado,

não tem nada haver uma coisa com a outra.

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.

esqueci de mencionar o SPORE

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.