O Bill de hÓra publicou um post sobre um assunto que me interessa enormemente. Ele comentou sobre a dificuldade de se projetar boas APIs e protocolos.
Para quem não o conhece, o Bill de hÓra foi o co-editor da RFC do AtomPub, o protocolo de publicação do formato Atom. No post ele comentou sobre a dificuldade de elaborar um bom protocolo de comunicação (no caso o AtomPub). O trabalho demorou mais de 2 anos para ser concluído, e neste 2 anos não contam o tempo no qual o Joe Gregorio (o outro editor da RFC) já estava trabalhando no protocolo antes.
Uma observação que ele faz é que é difícil encontrar indivíduos capazes de projetar boas APIs, e bem mais difícil é encontrar indivíduos capazes de projetar bons protocolos de comunicação. Algumas pessoas dizem que essas habilidades (projetar APIs e projetar protocolos) são de certa forma opostas, o que implica que seria especialmente difícil encontrar pessoas com habilidade nas 2 coisas.
Ler esse post foi motivante e inspirador para mim. Neste exato momento eu estou fazendo as duas coisas simultaneamente. Meu time é responsável pelo sistema de cadastro de usuários e autenticação da Globo.com, entre outras coisas. Esse sistema é provavelmente o que possui mais clientes internos na empresa. A implementação original utilizava EJBs para comunicação remota entre clientes e o servidor, e permitia apenas clientes Java.
Estamos progressivamente saindo dessa estrutura. Estamos implementando novas interfaces e clientes que usam serviços REST na comunicação, em vez dos EJBs. Isto está sendo feito de forma progressiva porque nenhum Product Owner daria alto valor de negócio para uma migração dessas, exceto em situações extremas (que não são nosso caso).
Pois bem, nesta migração eu estou atuando nas 2 frentes que o Bill de hÓra classificou como desafiadoras. Estamos modelando os serviços REST e o novo protocolo de comunicação. E estamos também implementando uma API Java para realizar as operações através deste novo protocolo.
Sem dúvida esta migração é desafiadora. De fato não é fácil elaborar um bom protocolo e uma boa API. Porém, isto também motiva demais. Quem acompanha o meu blog já sabe do meu apreço por serviços REST. Assim, este trabalho atual tem sido ótimo para conseguir explorar inúmeras situações envolvidas neste tipo de comunicação.
Para minha sorte, pude contar com alguns pontos facilitadores. Na elaboração do protocolo, o conhecimento do AtomPub ajuda muito. Eu já conheço bem esse protocolo e tinha desenvolvido serviços REST em alguns projetos, então essa parte da empreitada ficou muito facilitada.
Além disso, o conhecimento da API Java anterior do projeto traz várias idéias que podemos explorar. Algumas decisões na API anterior foram muito boas, e outras trouxeram alguns problemas. Eu não participei da implementação original do projeto (isso foi em 2004), mas após trabalhar no projeto por bastante tempo, consegui vivenciar bem os problemas dela. O principal era o alto acoplamento entre o servidor e os clientes, então isso é o principal ganho que pretendemos ter com essa nova implementação baseada em REST.
O outro ponto facilitador é estar no mesmo time que o Silvano, certamente um dos melhores caras que já conheci tecnicamente. Nós temos visões complementares sobre a arquitetura e a implementação. As idéias que colocamos na prática após as freqüentes discussões são muito superiores às que eu ou ele seríamos capazes de desenvolver individualmente. Com a liberdade de decisões técnicas que temos na Globo (principalmente após a adoção do Scrum), conseguimos evoluir nossas aplicações progressivamente, sempre avaliando pontos positivos e negativos das decisões anteriores.
Após ler esse post do Bill, tive uma dimensão melhor da grandeza do desafio que estamos tendo agora. Isto traz ainda mais motivação, e não abala a confiança. Tenho a mesma sensação que Isaac Newton teve ao dizer que “se ele pôde enxergar mais longe foi porque se apoiou nos ombros de gigantes”.
Quando estamos trabalhando freqüentemente com padrões e tecnologias abertas, temos sempre essa vantagem. Viver no mundo open source é se apoiar sempre nos ombros de gigantes, e então qualquer desafio fica muito mais suave e a nossa confiança aumenta. É por isso que eu amo o que faço 
Bruno,
Há uma palestra do Joshua Bloch sobre o assunto: http://www.infoq.com/presentations/effective-api-design
Resumo: A well-written API can be a great asset to the organization that wrote it and to all that use it. Given the importance of good API design, surprisingly little has been written on the subject. In this talk (recorded at Javapolis), Java library designer Joshua Bloch teaches how to design good APIs, with many examples of what good and bad APIs look like.
Abraço
Oi Alan, eu tinha visto essa apresentação quando ela saiu, mas foi ótimo você comentar, para eu assistir de novo
O Joshua Bloch é fera demais, devemos nos inspirar nas enormes contribuições que ele já fez. Especialmente à plataforma Java e com o Effective Java.
Bruno, muito motivante suas palavras. Pena que
a globo.comas empresas privadas não transformem alguns dos seus projetos em open source. Assim, retribuiriam a ajuda que tem utilizando projetos open source e contribuiriam com a comunidade de software com seus excelentes profissionais.Oi Joel, quanto às empresas privadas em geral eu não sei dizer. Mas a Globo.com está com iniciativas bem legais no que diz respeito a open source e o pessoal inclusive já está revendo os contratos de trabalho dos funcionários para que seja possível transformar produtos internos em aplicações open source. Eu achei isso bem legal.
A Globo.com está ligada de forma cada vez mais forte à comunidade open source e creio que isso só irá aumentar. Não tenho idéia de tempo, mas tudo leva a crer em no futuro de médio prazo a empresa estará contribuindo de forma mais ativa com projetos open source. Aqui dentro a força de produtos e iniciativas open source só aumenta e eu acho isso excelente.
[]s