O Guilherme Chapiewski acaba de postar sobre uma conversa que tivemos hoje que, como sempre, começou na baia, passou por 3045 livros, papers e blogs e acabou num sanduíche de mortadela.
Afinal, qual a diferença entre POST e PUT numa arquitetura REST?
Fui convidado pelo pessoal da Caelum para participar do Falando em Java 2007. Achei a idéia dos rapazes fenomenal: uma conferência rápida sobre um tópico atual a um preço acessível. Você paga R$200,00 para ir num Sun Tech Days da vida e passear por 2.545 palestras que falam superficialmente sobre um milhão de coisas e não aprendendo muito além de que se você usar Netbeans você vai ser mais feliz, mais gostosão e sua alma não vai para o Inferno, mas se você está cansado disso pode preferir pagar R$40,00 e ter um dia com 5 palestras sobre coisas que você precisa saber pra ontem. A grade inclui indexação e busca de conteúdo, REST, APIs públicas, JavaFX e AJAX, tudo girando em torno do tema Web 2.0.
Enquanto o GUJ tem sua massagem noturna eu respondo ao post do Maurício por aqui. O tema é REST x POX, mais especificamente: precisamos usar REST o tempo todo?
Pra você que estava hibernando há uns 12 meses, REST é um estilo arquitetural que se coloca como uma alternativa ao uso de SOAP e padrõesWS -* para criar WebServices. REST é interessante porque este estilo arquitetural é conhecido e utilizado há anos: é o estilo arquitetural que define a Web. Um sistema REST vai usar os métodos HTTP (GET, POST, PUT e DELETE), os content-types, os código de resposta e tudo mais que você ignora solenemente na maioria das aplicações web atuais mas que estão desenvolvidas e especificadas há mais de uma década.
Um possível problema seria de que as pessoas estão dizendo que usam REST quando na verdade apenas usam XML passando por HTTP, o chamadoPOX ( Plain Old XML, um primo do POJO). Este processo é exatamente a mesma coisa que utilizar SOAP com HTTP, exceto pelo fato de que o XML é personalizado (ao invés de 500 envelopes, um dentro do outro) e que não temos umWSDL (o que provavelmente é ruim).
Bom, a pergunta do Maurício é: isso é ruim? A resposta você já sabe: depende, mas depende do quê?
Quando se usa WebServices SOAP ou REST o que se quer é ter uma interface padronizada para um serviço. Há décadas nós temos serviços distribuídos sendoamplamente utilizados, o motivo de existir SOAP e outros é padronizar este ecossistema. Quando você padroniza algo como o protocolo de interface remota de todas as aplicações obviamente você vai pagar um preço em eficiência. Uma aplicação que segue um protocolo genérico como HTTP provavelmente não será tão eficiente em comunicação remota quanto um que segue um protocolo específico e especializado.
A partir do momento que você resolve utilizar uma interface genérica você assina um contrato. Se você me disser que seu sistema éRESTful eu tenho certeza que se eu fizer a requisição de um objeto inexistente seu sistema irá retornar um código de erro 404, e não um código 200 com um XML bonitinho e uma mensagem de erro. 200 pra mimsignifica uma só coisa: “Ok, o objeto existe e seu conteúdo segue no corpo da mensagem”.
Ao fazer POX você quebra esta regra. Pode ser que seu sistema seja simples e que definir um mini-protocolo baseado em POX seja uma ótima solução, mas você acaba de inventar seu próprio padrão, que é exatamente o que o uso de WebServices tenta evitar. Mesmo para sistemas legados com seus próprios padrões (coisinhas em COBOL, por exemplo), nós temos oESB como tecnologia que converte mensagens para um formato intermediário, de modo que não sejam criados seus próprios padrões. A idéia por trás de REST não é abolir padrões mas sim ter uma especificação simples e eficiente, com um mínimo de primitivas e máxima extensibilidade.
A IBM é uma empresa que não inova. Deixou de ser o grande líder do mercado há décadas para se tornar um seguidor, e dos bem fraquinhos. O IBM AlphaWorks, entretanto, é uma das poucas coisas que sobrevive em termos de inovação da IBM. Eu recebo a newsletter há alguns anos e é sempre uma das primeiras mensagens a serem lidas quando chegam.
Talvez por essa esperança toda que me decepciona fortemente ver que as pessoas ainda, em 2007 (notou que “em 2007″ é uma expressão recorrente minha há algum tempo?) as pessoas ainda insistem em conexões com bancos de dados feitas pelo cliente. Saber disso realmente é frustrante como desenvolvedor.
Bancos de dados como coração da empresa já foram uma técnica válida. Era o único middleware que prestava ou era viável no cenário de algumas muitas décadas atrás. Hoje as pessoas querem SOA, querem componentes reutilizáveis e… continuam insistindo em repositórios de dados centralizados.
Certa vez a equipe que eu coordenava passou por um problema nessa área. Como parte do lançamento de um novo produto tivemos que eliminar algumas tabelas e mudar o schema de dados. Apesar daquele esquema só ser utilizado completamente pela minha equipe, sabíamos que algumas pessoas estavam fazendo consultas neles. Alguns greps no CVS (infelizmente não usávamos SVN) e vimos que três projetos usavam as tabelas que eliminamos e que quase todos usam as outras. A solução do mundo dos SGBDs corporativos é uma só: faça uma view e mantenha ela no ar enquanto as pessoas não alterarem, testarem, homologarem e instalarem seus sistemas modificados.
Esta foi uma epifania, as pessoas acordaram e vimos que precisávamos racionalizar isso. A solução veio na forma de um arquivo JAR que continha um cliente padronizado fazendo consultas em JDBC diretamente ao banco de dados. Eventualmente construímos alguns WebServices REST (como quase sempre, SOAP não fazia sentido) e os clientes que se conectavam ao banco foram migrados para versão que conectava-se ao REST. Quem teve o trabalho de se adaptar a primeira versão não precisou de mais anda para migrar para uma arquitetura SOA.
Quantas vezes vamos ter que resolver este mesmo problema até que todos percebam que bases de dados são apenas partes de sistemas?
Dia desses estava programando em par com um amigo quando encontramos um problema. Estávamos utilizando o excelente XStream para transformar um domain model em algo que pudesse ser consumido via webservices de arquitetura REST quando percebemos que nossos XMLs iam ficar enormes e com uns 40% de informações repetidas. Simplesmente haviam dados que eram comuns a várias entidades sendo serializadas em uma lista e se repetíssemos os dados para cada entidade serializada teríamos um grande problema.
Conversando com o Guilherme, ficamos sabendo que o XStream possibilita o uso de referências. Infelizmente também descobrimos que isso só funciona se você tem várias referências para o mesmo objeto (ou seja: tem que ser ==, não basta ser equals()). Seguindo indicações do Guilherme, vimos que para alterar este comportamento deveríamos mexer em uma classe específica que, a princípio, poderia ser estendida por uma subclasse nossa.
Aí a falta que faz seguir o Open-Closed Principle (OCP. E não, não é a ) se faz cruel. O OCP foi difundido por Bertrand Meyer, um dos papas da OOP, e diz:
Um módulo (uma classe, por exemplo) deve ter uma interface rígida e encapsulada para uso por outros módulos e ao mesmo tempo ser aberta e flexível apra ser estendida por estes.
Basicamente isso te dá uma diretiz para que crie métodos bem-definidos, não deixando vazar muita informação sobre o que sua classe faz mas ao mesmo tempo faça com que se alguém tiver que estender esta classe isso seja um processo sem dor. Se você não está interessado em deixar que outras pessoas estendam sua classe marque-a como final e acabe com o mal pela raiz.
Bom, ainda que seja uma biblioteca (não, não é uma API!) fantástica, o XStream peca neste quesito. A classe que faz esta comparação é inserida dentro de outra como atributo private e sem setter public ou protected. A primeira tentativa foi utilizar reflection para injetar os atributos ‘na marra’, a reflection em si funcionou mas… descobrimos que tratava-se de uma classe estática definida dentro de outra. Depois de ler algumas dezenas de linhas de código e escrever outras desistimos.
Percebemos um problema porque a quantidade de código que necessitávamos para adaptar o módulo foi crescendo muito. Eram várias horas de desenvolvimento e ainda não tínhamos uma solução aceitável, mas a base de código só crescia. Todos aquele código tomou tempo para ser criado (utilizando TDD) e demandaria ainda mais tempo para ser mantido no decorrer do projeto.
Simplesmente estávamos horas envoltos em código que não tinha nada a ver com a aplicação que estávamos desenvolvendo, nossa missão não era criar um serializador de XML mais flexível e sim transformar meia dúzia de objetos em XML utilizando uma ferramenta de mercado.
Daí, para a infelicidade de nossos egos de programadores, decidimos partir para uma solução simples (manter uma lista no contexto de marshalling do que já havia sido serializado e modificar nossos adapters) que atendia nossas necessidades. Não era tão cool, não usava recursos obscuros da linguagem… mas nos permitiu voltar a fazer o que somos pagos para fazer: aplicações.
Todo programador gosta de hackear uma biblioteca, um subsistema ou qualquer coisa que tenha sido feita por terceiros. Aliás, eu diria que bons programadores obrigatoriamente gostam disso. O problema é que existe um ponto em que a brincadeira deixa de ser produtiva e passa a ser mera masturbação tecnológica.
Ótimo painel sobre o futuro da programação no JAOO. Especialmente o comentário do PragDave:
Dave: I’d like to predict that the current stacks of software by 10-15 years are going to be in a much worse legacy and more of a nightmare to maintain. You’re going to have employment forever maintaining this stuff. C++, Java code, C# code, this stuff is very complicated and very brittle with all these class libraries and frameworks. We’re digging ourselves in a really big hole and there will be a lifetime of opportunities for you people to maintain this stuff that you’re creating.
Prepare-se e pense nisso antes de comprar aquela ferramenta mágica ou criar mais um framework que faz a mesma coisa que todos os outros.
Comento em breve o evento mas os slites já estão disponíveis:
O DQO continua com a conversa sobre REST x WS-*.
Na argumetnação do porque-você-não-pode-simplesmente-ignorar-ws-* entram dois pontos centrais:
a) WSDL
b) REST é para HTTP apenas
Quanto a (a), eu também tinha a impressão que uma linguagem de definição de interfaces é fundamental mas mudei de idéia. Essas IDLs geralmente são muito complexas (desde CORBA) e isso está intrínseco ao fato de que devem definir tipos simples, tipos complexos, tipos do usuário, etc. de maneira auto-contida. Uma lignaugem de tipos genérica não tem como ser muito simples.
Quanto a ser editado manualmente, EJBs também foram criados apra serem editados apenas por ferramentas. Assim como eu tenho que editar EJB-Jar.XML todo santo dia eu tenho que editar WSDLs. temos um padrão aqui? Fora que os bindings SOAP para linguagens como PERL são…sofríveis. Na melhor das hipóteses. Enquanto isso qualquer coisa que faça HTTP e trate um formato como XMl está pronto para REST.
O ponto é que se eu tenho um conjunto de primitivas simples como PUT, GET, POST e DELETE eu não rpeciso de muito mais. parsers XML, YAML, JSON existem aos milhares e basta ser bem documentado para saber o que uma estrutura de dados representa.
Quanto ao ’ser HTTP-only’, sim, é uma limitação que pode não permitir o uso de REST out-of-the-box em alguns cenários. Mas SOAP, apesar de não ser dependente de transporte, não possui até onde eu sei especificações formais para o uso de JMS ou qualquer outra coisa que não seja HTTP. O que existe são implementações proprietárias destes transportes, e nada impede a criação de uma bridge JMS-HTTP, até via ESB.
Acho que o único motivo técnico real para o uso de SOAp é a abundância de ferramentas e suporte em diversos produtos. Em termos de integração, REST parece fazer muito mais sentido na maioria dos casos.
Começa um debate com base em uma entrevista publicada no InfoQ. Sanjiva Weerawarana defende as especificações que ajudou a criar, a famosa pilha WS-*.
Do outro lado, um oponente que até pouco tempo atrás pouco se ouvia falar sobre e agora temos até uma JSR. Não que você precise disso para utilizar REST, muito pelo contrário. Para usar REST tudo que você precisa é de algo capaz de fazer uma requisição HTTP e tratar o formato dos dados, seja XML, seja JSON, seja YAML ou o que quer que seja.
Tudo isso sem reinventar protocolos, sem ignorar as características do HTTP, sem criar mil e um consórcios para produzir duas mil especificações redundantes entre si. Mais sobre o tema em breve.