Dúvida com REST

Continue lendo…

Mais abaixo

Ora, mas a idéia é exatamente essa, de que não exista novidade nenhuma

Com REST a idéia não é que você tem serviços, mas que você tem recursos ( cada um identificado pela sua própria URI ) que podem sofrer operações através de uma interface comum do seu protocolo. Esses serviços fazem as vezes dos “serviços” do SOAP mas de uma forma diferente, em REST quando você acessa um recurso qualquer você está acessando uma das possíveis representações dele (ele não precisa ser um documento XML como em SOAP, por exemplo), ele pode ser um documento XHTML comum, um objeto no formato JSON ou qualquer outra coisa que você precise.

Imaginemos uma aplicação REST rodando em cima de HTTP que sirva pra buscar informações sobre o CEP como o WS de CEP dos correios. Diferentemente de SOAP, REST não ignora o protocolo sobre o qual ele está rodando, ele faz uso de tudo o que o protocolo oferece, então na hora de fazer a busca pelo nosso cep ( digamos “58075-300”)aconteceria o seguinte:

• Cliente faz a requisição HTTP GET para: rest.correios.com/ceps/58075-300
• A aplicação rest dos correios busca por um cep (o recurso) que tenha como identificador o código “58075-300”, se ele encontrar, vai retornar para o cliente uma resposta HTTP 200 com o recurso cep (com rua, cidade, estado e blablabla) e além disso vai colocar os cabeçalhos HTTP “Last-Modified-At” e “Expires” (informações de CEP não mudam com frequência, então ele pode botar essa informação pra expirar daqui a um mês ou talvez até mesmo um ano)
• O cliente recebe a resposta, guarda a representação no seu cache (como qualquer navegador web comum faria) e faz o que tinha que fazer com as informações do CEP

Se o cliente tentar pegar mais uma vez informações do mesmo cep, ele não vai mais ao site dos correios, ele vai direto pegar a representação que já está disponível no seu cache.

E como aplicações REST não guardam estado dos seus clientes (e essa roda em cima de HTTP, que é um protocolo sem estado por natureza) esse serviço pode ser facilmente espalhado em diversas máquinas.

blz…

então, se “seguindo” o padrão REST eu ja tenho tudo q preciso pra me comunicar com outros sistemas,qual a necessidade de se usar SOAP,AXIS etc?

SOAP é uma coisa, REST é outra, ou é um ou é outro, você não usa os dois, você escolhe um dos dois.

e o q eu ganho usando SOAP?

Dores de cabeça, calvície e impotência.

Dores de cabeça, calvície e impotência.

o que eu não entendo é o seguinte:
1 - tudo que eu posso fazer com SOAP eu tambem posso fazer sem SOAP?
2 - se REST existe desde sempre,pq não é usado desde sempre(não no caso de WS)?

Não tudo… como orquestração, operações transacionais…

Cultura, dou graças a deus que a tecnologia evolui…

então,apenas nos casos citados(transação,orquestrações) SOAP é algo justificável?
Onde mais?

raf4ever:

então,apenas nos casos citados(transação,orquestrações) SOAP é algo justificável?
Onde mais?

Orquestrações e transações podem ser feitas com REST também

Agora mensageria assíncrona é uma coisa difícil de se fazer com REST em cima de HTTP. SOAP vai ter um dia “Reliable messaging”, então pode ser que ele venha a ser melhor que rest nesse caso, mas tudo deve ser avaliado caso a caso, não dá pa se assumir as coisas tão preto no branco assim sem conhecer a realidade do problema.

Então você faz o seguinte, tenta fazer com rest, se não der, parte pra SOAP

agora chegamos onde eu queria…
O problema é que tenho visto por ai o REST ser apontado como a “salvação da lavoura”,e quis saber se tudo que fiz e tenho feito
com SOAP era tão “1990” assim…

Abraços

Mas REST é a salvação da lavoura pra 99% das necessidades (medido com o Istatistical Medidator Tabajara)

Falando sério, SOAP complica demais pra todos os casos, não existe simplicidade pro que é simples. REST é simples pra todos os casos, se você precisar de alguma coisa complexa demais e que seja difícil demais de se fazer com REST, é aí que você poderia partir pra SOAP.

Continuando…
SOAP só se você não poder escolher outra coisa, e ainda assim sendo forçado
e em muitos casos não precisaria ser usado…

Cara, desde que entendi como o REST funciona fico me perguntando quase que sempre em que cenário vou precisar de SOAP a não ser por imposição do cliente.

Pois é…
a coisa é tão “estupidamente” simples que tô me perguntando isso tambem

Pois é…
a coisa é tão “estupidamente” simples que tô me perguntando isso tambem :D

Tem empresas e principalmente órgãos públicos que não aceitam algo simples, como justificar a aquisição de toneladas de tools a preços exorbitantes se é para usar com REST?

Só lembrando, REST é stateless, que no final das contas dá para simular no servidor

Seria bom saber se alguém já implementou algo statefull com SOAP.

Entendo perfeitamente que REST é mais simples que SOAP. Mas em Java, existem ferramentas e frameworks pra se fazer serviços REST?

Pra mim, dá a impressão que a única alternativa seria usar Servlets, o que minaria qualquer simplicidade do protocolo.

http://www.google.com.br/search?q=java+rest&ie=utf-8&oe=utf-8&aq=t&rls=com.ubuntu:pt-BR:official&client=firefox-a

já…

já…

Você implementou? O que era? Porque não fez stateless?

Manter estados em web services é ainda mais assustador que gravar dados na sessão http do usuário.

já…

Você implementou? O que era? Porque não fez stateless?

Manter estados em web services é ainda mais assustador que gravar dados na sessão http do usuário.
Web Services statefull, isso me assusta bastante também.

Leonardo3001:

Entendo perfeitamente que REST é mais simples que SOAP. Mas em Java, existem ferramentas e frameworks pra se fazer serviços REST?

Pra mim, dá a impressão que a única alternativa seria usar Servlets, o que minaria qualquer simplicidade do protocolo.

O Struts 2 tem toda infraestrutura necessária usando um plugin daqueles para JSON, coisa assim…
Acredito que todos os frameworks action-based em Java já estão preparados para REstful

Why?

Essa de statefull realmente precisa ser explicada…

Why? :D

Colocar dados em sessões HTTP já é uma coisa complicada quando você precisa fazer balanceamento de carga ou cluster (“ah, mas o meu servidor de aplicações tem um cluster de sessões”, eu também acredito em papai noel), em web services a gambiarra é maior ainda porque tecnicamente web services seriam apenas funções e funções não tem “estdo”, se você está mantendo estado entre as chamadas de funçõs tem alguma coisa errada com a sua lógica.

cmilfont:

Leonardo3001:

Entendo perfeitamente que REST é mais simples que SOAP. Mas em Java, existem ferramentas e frameworks pra se fazer serviços REST?

Pra mim, dá a impressão que a única alternativa seria usar Servlets, o que minaria qualquer simplicidade do protocolo.

O Struts 2 tem toda infraestrutura necessária usando um plugin daqueles para JSON, coisa assim…
Acredito que todos os frameworks action-based em Java já estão preparados para REstful

Então, eu tenho dúvidas se isso é verdade. O protocolo REST faz uso de GET, POST, PUT e DELETE, e pelo que sei, o Struts 2 não te dá controle sobre esse tipo de configuração (mas posso estar enganado).

Leonardo3001:

Então, eu tenho dúvidas se isso é verdade. O protocolo REST faz uso de GET, POST, PUT e DELETE, e pelo que sei, o Struts 2 não te dá controle sobre esse tipo de configuração (mas posso estar enganado).

Struts2 voce tem controle sim, no JSF que voce só tem controle do POST, mesmo assim já li por aí que tem como gambiarrar o JSF para fazer funcioanr os outros metodos HTTP, mas JSF não é action-based como falei, continuo achando que todos os modernos action-baseds estão preparados para Restful mesmo que usando um plugin.

Fala Galera!!

Não usamos REST como disse nosso amigo porque criamos essa cultura, alguém um dia disse para você usar SOAP para garantir interoperabilidade, bla bla bla…

O que admiro no REST:

:arrow: Simplicidade!
:arrow: Performance!

Um amigo já chegou a usar Mule(ESB) com REST + Spring, ficou muito show!

Abraços!

Leonardo3001:

Então, eu tenho dúvidas se isso é verdade. O protocolo REST faz uso de GET, POST, PUT e DELETE, e pelo que sei, o Struts 2 não te dá controle sobre esse tipo de configuração (mas posso estar enganado).

Ou eu não sei nada ou REST é um estilo arquitetural não um protocolo. Não veremos “toolkit” ou outros milagres para um estilo arquitetural. (Talvez alguns exemplos, guidelines… )

Para mais informações: http://archsofty.blogspot.com/2008/01/rest-breves-esclarecimentos-sobre-o.html

Como assim não veremos toolkits?

Já existem diversos toolkits tanto pra Java como pra outras linguagens pra se desenvolver aplicações usando REST em cima de HTTP.

E um deles é o Jersey -> https://jersey.dev.java.net/

Maurício Linhares:

Como assim não veremos toolkits?
E um deles é o Jersey -> https://jersey.dev.java.net/

Certo, você está correto. Acho que me expressei mal…
O Toolkit que digo para não esperarem é do tipo que vai aplicar todos os conceitos do estilo (REST) a uma aplicação… os existentes auxiliam a aplicabilidade do estilo.