Deve haver uma padronização do REST?

This message was edited 1 time. Last update was at 18/09/2009 11:49:19

Bill Burke, um dos principais líderes do JBoss e envolvido especialmente com a implementação de Rest-WS do mesmo, acaba de lançar o site REST-*:

http://rest-star.org/

O site visa criar especifições e centralizar boas práticas em relação ao REST, tendo em vista que o mercado anda tão confuso. De acordo com Bill, "SOAP has failed as an interoperability protocol", e o REST é uma alternativa forte e viável para preencher essa falha. Duas especificações já foram ciradas: transações e mensageria.

A idéia de criar padrões para o REST não é recente, aqui no GUJ já se discutiu a respeito da criação de uma linguagem de descrição para REST aos moldes da IDL e da WSDL. Há opiniões divergentes. Jim Webber, que esteve no Brasil, gosta de dizer que a WEB vai tomar o lugar do middleware, e os parões que já conhecemos serão usados. Roy Fielding, "criador" do REST, é avesso a idéia de padronização a la W3C, e não poupa palavras:

http://thread.gmane.org/gmane.comp.web.services.rest/10459/focus=10472

Mais informações sobre a criação do site:
http://bill.burkecentral.com/2009/09/16/rest-org-launched/

E você, o que acha?

GUJ Master Membro desde: 20/05/2009 11:21:32 Mensagens: 1776 Offline

Se é verdade que transações distribuídas e descricao de serviços estão incluidas nessa especificação é sinal de que pode ser qualquer coisa, menos REST.

JavaTeenager Membro desde: 29/08/2009 21:19:32 Mensagens: 194 Offline

Paulo Silveira wrote:
Jim Webber, que esteve no Brasil, gosta de dizer que a WEB vai tomar o lugar do middleware, e os parões que já conhecemos serão usados. Roy Fielding, "criador" do REST, é avesso a idéia de padronização a la W3C, e não poupa palavras:

Jim Webber já trabalhou com CORBA ? E REST é para algo pos-legado ou melhor atendente outros padrões, e não WS*.

JavaTeenager Membro desde: 29/08/2009 21:19:32 Mensagens: 194 Offline

mochuara wrote:Se é verdade que transações distribuídas e descricao de serviços estão incluidas nessa especificação é sinal de que pode ser qualquer coisa, menos REST.

Acho que é bem por ai também.

Estará o pessoal buscando a eterna "BALA DE PRATA" querendo atribuir (novamente) super poderes a uma alternativa de comunicação ?

Quando será que estes "genios" vao perceber que não existe uma bala de prata ?

Padronização eu não digo, mas se tiver algum lugar pra consultar as "boas práticas" vamos dizer assim... então acho válido.

Daí a tornar um padrão nos moldes de W3C, etc... aí já acho besteira.

GUJ Expert Membro desde: 18/02/2008 16:17:53 Mensagens: 3002 Offline

Eu posso muito bem estar falando besteira mas:

O que tem para ser padronizado em REST? Que dificuldades de interoperabilidade estão encontrando nele?

This message was edited 1 time. Last update was at 19/09/2009 12:32:56

Bruno Laturner wrote:Eu posso muito bem estar falando besteira mas:

O que tem para ser padronizado em REST? Que dificuldades de interoperabilidade estão encontrando nele?

A questão não é "interoperabilidade", mas como o melhorar o "como se faz", de algumas implementações para problemas clássicos da computação enterprise (transação distribuída, mens. publisher/subscribe, process workflow, etc) em Rest.

Vejam por exemplo o clássico problema de mensageria e o uso de Atom Publisher:

http://www.jboss.org/reststar/specifications/messaging.html

Virtual Machine Man Membro desde: 21/01/2004 14:12:54 Mensagens: 719 Offline

mochuara wrote:Se é verdade que transações distribuídas e descricao de serviços estão incluidas nessa especificação é sinal de que pode ser qualquer coisa, menos REST.

Qual é o fundamento desta afirmação?

O SOAP/WS-* de hoje é o REST de amanhã

JavaTeenager Membro desde: 29/08/2009 21:19:32 Mensagens: 194 Offline

Rubem Azenha wrote:O SOAP/WS-* de hoje é o REST de amanhã

Com Spring REST faz mais sentido.

GUJ Ranger Membro desde: 04/07/2007 18:28:58 Mensagens: 975 Offline

Alessandro Lazarotti wrote:A questão não é "interoperabilidade", mas como o melhorar o "como se faz", de algumas implementações para problemas clássicos da computação enterprise (transação distribuída, mens. publisher/subscribe, process workflow, etc) em Rest.

Vejam por exemplo o clássico problema de mensageria e o uso de Atom Publisher:

http://www.jboss.org/reststar/specifications/messaging.html

Sabe qual a diferença entre as comunidades de C++, Python e Ruby e as comunidades de Java e .Net? Simples, as primeiras tratam os programadores como adultos, enquantos que os outros preferem (em sua maioria) ser infantilizados. Qual é? Pra quê criar uma comunidade, com o braço-forte da JBoss, para definir o que é melhor? Será que é porque os programadores são muito estúpidos pra pensar por si mesmos? Ou é porque, como a JBoss vende produtos para gerentes, precisa concordar com eles de que programadores são burros mesmos?

Outra, por que fazer uma mensageria? Usar feeds não basta? Pedir que os clientes acessem determinada URL de tempos-em-tempos para buscar atualizações não é suficiente? Não é melhor usar aquilo que se está sendo praticado na web, ao invés de tentar maquiar o REST naquela mesma oferta de produtos que as "vendors" sempre vende?

Alessandro Lazarotti wrote:

mochuara wrote:Se é verdade que transações distribuídas e descricao de serviços estão incluidas nessa especificação é sinal de que pode ser qualquer coisa, menos REST.

Qual é o fundamento desta afirmação?

REST é stateless e transação depende de estado. Logo as duas coisas são incompatíveis. Ponto.

Transação distribuída é uma decisão arquitetural imbecil, não importa por onde se olha. Mas infelizmente, as empresas tradicionais sempre contratam estúpidos para serem arquitetos, e estes, na sua irracionalidade, acabam fazendo softwares que exigem mais do que deveriam (incluindo sincronismo entre várias máquinas).

Sempre existem formas, pelo menos num nível macro das interfaces de serviços, de se livrar de transação.

Achei a recercussão desse caso do Rest-* muito hilária.

Twiiters do Roy Fielding:
"@mraible Because the REST-* foundation is just more of the same promotional crap, claiming REST name while promoting the exact opposite."
http://twitter.com/fielding/status/4045154811

"140 characters is insufficient to express my contempt for JBoss and anyone who associates with such an unethical company."
http://twitter.com/fielding/status/4040710554

Comentário de Grame Rocher:
"Funny to see Burke/JBoss putting fingers in their ears and crying "I'm not listening" when the creator of REST @fielding scathes REST-*"
http://twitter.com/graemerocher/status/4074780005

Lol

GUJ Master Membro desde: 20/05/2009 11:21:32 Mensagens: 1776 Offline

JavaLivros wrote:

mochuara wrote:Se é verdade que transações distribuídas e descricao de serviços estão incluidas nessa especificação é sinal de que pode ser qualquer coisa, menos REST.

Acho que é bem por ai também.

REST implica em deslocar boa parte do fardo da comunicação para as extremidades da rede, ou seja, para os clientes. Assim REST consegue lidar com sistemas distribuídos da escala da internet, o que seria inviável numa arquitetura centralizada. Pra mim essa especificação pode se chamar qualquer coisa que eu não ligo (JBOSS-*), mas usar o nome REST não é certo se não há compromisso com os princípios que norteiam a arquitetura REST.

GUJ Master Membro desde: 20/05/2009 11:21:32 Mensagens: 1776 Offline

Bruno Laturner wrote:Eu posso muito bem estar falando besteira mas:

O que tem para ser padronizado em REST? Que dificuldades de interoperabilidade estão encontrando nele?

Se tem algo no REST que pode ser beneficiado de algum tipo de "padronização" é os chamados media-types (XHTML, ATOM, etc.). Mesmo assim me refiro padronização nos moldes do reconhecimento e da adoção maçica por parte da comunidade de usuários, não uma especificação que alguma empresa sem escrúpulos achou que é necessário.

Notícias, artigos e o maior fórum brasileiro sobre Java