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.
JavaLivros
Jim Webber já trabalhou com CORBA ? E REST é para algo pos-legado ou melhor atendente outros padrões, e não WS*.
JavaLivros
Acho que é bem por ai também.
chun
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 ?
febatata
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.
B
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?
Alessandro_Lazarotti
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?
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:
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?
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.
xymor
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-*"
Lol
M
mochuara
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.
M
mochuara
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?
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.
M
mochuara
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?
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.
Alessandro_Lazarotti
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.
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.
Leonardo3001:
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?
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.
Leonardo3001:
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?
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:
REST é stateless e transação depende de estado. Logo as duas coisas são incompatíveis. Ponto.
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:
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."
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.
qmx
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)
my 0.02
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.
Alessandro_Lazarotti
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.
Exato Paulo. Como ele continuou dizendo:
M
mochuara
Alessandro, voce esta desinformado ou então mal intencionado…
Board of Directors
The Board of Directors is responsible for approving new specifications and final draft of specifications. It is their responsibility to ensure the overall quality of our specifications and that their architecture fits seemlessly together. Red Hat, as the founder of REST-*, gets a permanent seat on the board. All other board members must be elected by the overall membership once a year. Any member may nominate an individual or company to be a board member before an election.
Curioso alguém dizer que este projeto REST-* é mantido pela comunidade sendo que ele mal existe ainda.
M
mochuara
Não sou contra a criação de uma comunidade para discutir REST e boas práticas. Mas não vejo motivo em criar algo nos moldes do JCP. Principalmente liderado por uma empresa com nenhuma expressão no assunto.
Alessandro_Lazarotti
Mochuara, rest-* foi uma iniciativa de Bill Buke, e ele lutou por isso dentro da Red Hat, acredite. Ele é mantido sim pela comunidade e conta com o feedback dos participantes. Existe regras para a formação do conselho, obviamente, e sendo iniciado por red haters, claro que a empresa tem cadeira permanente no conselho, assim como a Sun no jcp, o que não inviabiliza o processo.
Não entendi o ponto em questão. A comunidade mal existe e o projeto mal existe, ambos caminham juntos, isso é comum no meio open source. Mais curioso ainda é dizer que a empresa não tem expressão no assunto sendo criadora e mantenadora de uma das primeiras implementações JAX-RS e fomentar na comunidade Java a utilização do modelo Rest.
Volto a dizer, ser contra as idéias da especificação proposta e da própria comunidade é excelente através de argumentos técnicos, fomentar “discussão” sempre é bom. Infelizmente esse tipo de discussão esta cada vez mais difícil de encontrar.
L
Leonardo3001
Alessandro Lazarotti:
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.
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 JCR? 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.
Eu não disse ser infantil, mas ser infantilizado. A diferença é sutil, mas é importante. Vejo a comunidade Java mais como uma aristocracia, porque existem poucas empresas (e cada vez diminuindo à medida que as fusões acontecem) que tomam a maioria das decisões, e o restante simplesmente acata porque acredita que a nata está fazendo o melhor para todos, ou seja, se infantilizam. Claro que, como ninguém vigia os vigilantes, a nata toma decisões que são melhores para si.
É possível mudar? Dificilmente. Leio as mudanças propostas na JSR, e percebo que as mudanças visam a interesses das empresas envolvidas em vender alguma coisa. Os principais projetos open source são monstros administrados por organizações, onde: a) dependem de CGLIB ou ASM, que são coisas que um programador comum não conhece; e b) os principais mantenedores são empregados da própria organização. Para um programador Java, só é possível participar ativamente em Open Source em projetos marginais.
Portanto, é falsa a idéia de uma comunidade Java, seria até mais conveniente dizer sociedade Java.
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.
O que eu vejo: um funcionário da JBoss resolve lançar uma iniciativa de padronização, utilizando um domínio de rede da JBoss, criando boas práticas sobre mensageria e 2PC, que são ofertados através de produtos da JBoss. Como eu não posso ver conflito de interesses nisso?
Não tenho nada contra a existência da JBoss, da SpringSource, da Oracle ou qualquer que seja. Mas me incomoda essa falta de transparência, e o grande poder dessas empresas sobre o destino do Java em relação aos demais envolvidos. Não seria muito mais fácil a JBoss simplesmente dizer: “tenho interesses em criar produtos em cima de REST e preciso de uma padronização que me beneficia”?
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:
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."
Internamente, não importa se um serviço utilizar 2PC ou não. Se isso for transparente para os clientes, tudo bem. Da mesma forma que um SLSB pode realizar transação em dois bancos de dados, um POST numa URI também pode. O que desfigura o stateless é quando uma chamada de um serviço não configura “commitment”, seja um método de um EJB, seja um POST numa URI. E me parece isso que a “padronização” que propor.
Kenobi
Estou acompanhando de perto as especificações, por ora acredito que se quiserem contemplar todas as necessidades empresariais, como a citada - Atomicidade, depois segurança ( pois SSL é somente para point-to-point), REST vai deixar de ser simples.
WS*SOAP não ficou complexo à toa, era uma coisa muito simples e começaram a trazer o mundo de arquitetura distribuída como CORBA para dentro da especificação.
Eu não acredito em SilverBullet e SOAP já existe. Você pode endereçar necessidades com uma especificação e continuar com a simplicidade do REST para os casos mais triviais.
Rubem_Azenha
Kenobi:
Eu não acredito em SilverBullet e SOAP já existe. Você pode endereçar necessidades com uma especificação e continuar com a simplicidade do REST para os casos mais triviais.
Eu também penso assim… mas é uma discussão boa, algumas coisas o próprio protocolo HTTP fornece, outras tem que ser implementadas na mão.
Alessandro_Lazarotti
Você poderia citar exemplos de JSRs que “apenas” visam os interesses de empresas envolvidas em vender alguma coisa?
… será que essa não é uma opinião “pessoal” demais? Como já disse em outros posts aqui conheço “programadores java” que participam ativamente de projetos open sources de bastante destaque sem estar filiados a Oracle/IBM/RedHat/SpringSource. Qualquer pessoa pode contribuir com projetos Open Source. Se conhecer CGLIB for premissa para contribuir com um projeto, qual o problema? Será que conhecer uma ou outra tecnologia não é subjetivo demais “ao seu próprio conhecimento” para desmerecer as contribuições de algum projeto Open Source? Se você conhecesse CGLIB pensaria diferente… aliás, nem todos os projetos usam CGLIB não é mesmo?
Portanto? Pq você não contribui com o JCP ou pq você não conhece CGLIB ou ASM para contribuir com projetos Open Sources não marginais?
Importante salientar que: 1) o domínio jboss.org não tem vínculo comercial com linhas de produtos Red Hat, diferente por exemplo do domínio jboss.com. O mesmo acontece por exemplo com o fedoraproject.org 2)Não existe produto JBoss “comercializado” que envolva Rest… existe um projeto open source que é implementação da JAX-RS chamado RestEASY. Portanto a afirmação “que são ofertados através de produtos da JBoss” não faz sentido algum.
Quanto a transações e etc, releia as propostas e os drafts disponíveis na comunidade. Entenda que a questão varias vezes é realizar interface rest para vários serviços que não são naturalmente rest e podem se beneficiar da arquitetura.
[]'s
M
mochuara
Quer dizer que o Bill Burke/JBoss/RedHat está para o REST assim como a Sun está para o Java?? :shock:
Alessandro_Lazarotti
Alguém em algum momento disse isso? Não vejo onde esse tipo de discussão esta agregando em algo, sinceramente.
M
mochuara
Desculpa, esqueci de quotar no post anterior, vc disse (escreveu):
Sugiro que vc acompanhe a discussão na lista rest-discuss pra saber que toda a queixa se resume a esse ponto: A arrogância da JBoss de se colocar como autoridade na “padronização” do REST. A Sun não era só capacitada para exercer este papel como tb detinha os direitos da marca. Mas não é o caso com a JBoss. Tudo que ela fez sobre REST no mundo java foi um projetinho mixuruca de Servlet + URL Templates.
A verdade é que JAX-RS e suas implementações não colaram nem mesmo na comunidade Java! A maioria dos Restafarians Javaneses tinham adotado Restlet como framework REST preferido (e nem por isso o responsável pelo Restlet se achou no direito de propor tal absurdo).
Não sou contra a JBoss criar um wiki para reunir boas práticas sobre REST, mas não é essa a proposta inicial do REST-*. Alias, que péssima forma de se comecar um projeto.
Alessandro_Lazarotti
mochuara:
Desculpa, esqueci de quotar no post anterior, vc disse (escreveu):
Você novamente esqueceu de cotar um detalhe importante no que escrevi, mas vc deve saber disso:
Não é arrogância, é iniciativa. Ninguém é obrigado a seguir tais padrões assim como a Spring sempre não esteve aí para o JavaEE (bom, isso antigamente). O que muita gente não entendeu ainda é que a idéia não é engessar o Rest, mas discutir idéia de como solucionar problemas recorrentes no mundo corporativo, e isso não se restringe apenas a Rest mas a toda plataforma que possa fazer uso pelo menos de uma interface like REST, como componentes JavaEE. Não dá pra esperar a boa vontade de simplesmente “surgir”, sendo que as idéias já estão formadas na cabeça de alguém, como a de Burke. Um padrão só é padrão de fato se for seguido, portanto o tempo dirá se vingará ou não o projeto, simples…
Quanto a projetinho mixuruca, bom isso é opinião pessoal sua novamente, felizmente muita gente, mas muita mesmo, usa RestEASY na comunidade Java e isso afirmo com segurança e com base.
Desculpe, mas isso esta muito vago. Você tem esses dados? JAX-RS não pegou? De onde vem essa afirmaçào?Qual percetual de pessoas que usam Restlet comparados a quantas usam Jersey e RestEASY ou CFX? Não estou te atacando, é uma curiosidade que fiquei mesmo
Alessandro_Lazarotti
PS: alias, assim como o Hibernate se alinhou a implementação do JPA com sua extensão Hibernate EntityManager, o Restlet tbm tem sua extensão JAX-RS de alinhamento com o padrão.
M
mochuara
Alessandro, concordo que a JBoss pode fazer oq ue ela quiser. Mas o Spring, bom, ele se chama Spring, não Java-*, sacou?
E sim, JAX-RS não pegou é a minha opinião. RestEasy, Jersey, nada mais são que Servlets maquiados.
editado: O Spring tb não chegou reivindicando ser um padrão (na verdade foi justamente o contrário, ser uma alternativa ao padrão estabelecido).
