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:
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.
[quote=Bruno Laturner]Eu posso muito bem estar falando besteira mas:
O que tem para ser padronizado em REST? Que dificuldades de interoperabilidade estão encontrando nele?[/quote]
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:
[quote=Alessandro Lazarotti]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:
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?
Qual é o fundamento desta afirmação?[/quote]
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."
"140 characters is insufficient to express my contempt for JBoss and anyone who associates with such an unethical company."
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-*"
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.
[quote=Bruno Laturner]Eu posso muito bem estar falando besteira mas:
O que tem para ser padronizado em REST? Que dificuldades de interoperabilidade estão encontrando nele?[/quote]
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.
[quote=Leonardo3001]
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?[/quote]
A verdade é que REST não ajuda a vender “framework de controle” e servidores de aplicação.
Algumas empresas estão vendo sua atual linha de produtos se tornar obsoleta. Por sorte essa inciativa da JBoss não vai muito longe.
[quote=Leonardo3001]
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.[/quote]
Leonardo3001, não sei de seus problemas profissionais com a comunidade Java, birra com a linguagem, os times que você trabalhou ou que tem trabalhado, só sei que conheço muito profissional EXCELENTE desta mesma comunidade, onde sem exceção cada um deles cotribui de uma forma ou outra pela mesma. A comunidade não "trata" os desenvolvedores assim ou assado, a comunidade SÃO os próprios desenvolvedores, que guiam o norte. Você já leu alguma JSR? Participou de alguma discussão sobre as features de um novo release da linguagem com o grupo? Comitou drafts codes de algum proposal? É engajado em projetos open sources que possam ajudar essa comunidade? Então deixe de se colocar na posição "infantil", como você mesmo definiu, e ajude a mudar o quadro que você enxerga desta forma.
Você conhece o trabalho do Bill Burke? Por acaso ele não é um desenvolvedor? Ja viu as discussões que estão na comunidade do rest-start.org… por acaso são sobre futebol? Veja a besteira que você esta dizendo, pois partindo de sua análise: "Para que criar um Grupo de Usuário Java com o braço-forte da Caelum?", e aqui esta o GUJ ajudando, através de várias pessoas independente de sua liagação com a escola!
Para sua informação, não é uma iniciativa da "Red Hat Inc." o projeto Rest-.org, assim como também não é o jbossbrasil.org aqui no Brasil uma iniciativa da RH. O projeto rest- foi iniciado pelos colaboradores do RestEasy e é mantido pela comunidade, se você não concorda com muita das propostas, pode colocar seu ponto de vista e agregar ao que esta tentando ser feito. Assim como no Brasil, o jbossbrasil.org é uma iniciativa aberta de utilizadores e colaboradores dos projetos JBoss, onde a Red Hat não possue ligação direta. O próprio projeto resteasy não é vinculado hoje com nenhum produto JBoss comercializado pela Red Hat.
Por falar nisso, diversos comitters de projetos jboss.org não tem vínculos com a Red Hat e não é preciso ir muito longe pra ver isso, como é o caso de um conhecido professor da USP (comitter do JBoss AS) ou do "Parser Man" brasileiro que é comitter do Drools, do Hibernate e membro do expert group do JPA 2.0. Sem citar pessoas que você provavelmente já escutou o nome, como o Dan Allen que não era funcionário da Red Hat quando já contribuia enormemente com a comunidade, com decisões e com o código do Seam Framework.
Atom Publisher com feeds é uma forma de mensageria! Como ja linkei no outro post, a questão não é "funciona ou não funciona", é que o envelope para feeds pode ser simplificado, já que a intenção é trocar mensagens entre sistemas e não exibir notícias em seu blog. Exemplo de como seria tal proposta:
[code]Send---->
POST /topics/mytopic
Content-Type: application/json
<some json message message>
<—Response
HTTP/1.1 201 Created
Location: /topics/mytopic/messages/3332222
[/code]
Ahh, então eu não consigo em um SLSB realisar transações 2PC? Claro que consigo
Mas eu acho que a resposta que vc quer ouvir, pode ser a do Bill Burke:
[quote=Bill Burke]"Transactions are not considered a REST best-practice. In fact, they are a REST anti-pattern. Needless to say, some environments do have transactional requirements. Even if not purely REST, these applications should be able to take advantage of RESTful principals when interacting with a Transaction Manager.
REST-* Transactions is a specification that attempts to define a RESTful interface for 2-Phase-Commit transactions. It describes the interaction between coordinator services and transaction participants as well as how transactions can propagate in distributed applications."[/quote]
Acho muito interessante e saudável todas as opiniões (de qualquer espécie) sobre a adesão ou não de iniciativas quanto a especificações, padronizações ou implementações de frameworks que possam ajudar na TI, é assim que se contrói um futuro melhor na nossa área, discutindo e se acertando. Só não entendo a mania de perseguição, paranóia e teoria de conspiração de algumas pessoas… quanto a este fenômeno, eu apenas lamento.
Eu ainda continuo achando que os únicos interesses que são padrão nesse troço é o de players do mercado em se associarem à sigla REST, de qquer forma, a qualquer custo
Resumindo, mais uma manobra comercial… (o que nem sempre é de todo ruim, afinal ninguém vive de energia do universo no nosso mercado)
boa a frase do bill burke dizendo que mesmo transacao sendo uma ma pratica pensando em rest, quem precisa de transacao pode e deve mesmo assim tirar vantagem de uma arquitetura restful.
[quote=Paulo Silveira]boa a frase do bill burke dizendo que mesmo transacao sendo uma ma pratica pensando em rest, quem precisa de transacao pode e deve mesmo assim tirar vantagem de uma arquitetura restful.
