Microsoft também adere ao formato Atom para suas APIs

fevereiro 28, 2008

Atenção, este blog foi migrado para: http://brunopereira.org

Depois de o Google passar a usar APIs RESTful com o formato Atom, agora é a vez da Microsoft começar a usar este formato. Ontem a empresa anunciou que as APIs do Windows Live serão RESTful e farão uso do formato Atom.

Após alguns anos investindo pesadamente em web services WS-*, parece que a gigante de Redmond está lentamente mudando sua forma de pensar em serviços web. É claro que durante um bom tempo eles ainda vão defender ferrenhamente o uso da pilha WS-*, pois eles não querem jogar fora os investimentos nessa área para a plataforma .NET. Contudo, é sem dúvida interessante ver que talvez o maior defensor de WS-* está mudando de direção, embora ainda não de forma integral.

Como eu já havia comentado algumas vezes, parece que a adoção de web services REST para diversos fins vai mesmo crescer rapidamente e ocupar um bom pedaço do espaço anteriormente ocupado por WS-*. E mais, eu acredito que os serviços REST vão crescer muito como mecanismo de integração de sistemas e plataformas. É bastante provável que o uso de integrações com EJBs e outras tecnologias que te prendem a uma plataforma específica caia de adoção. Especialmente em aplicações de internet, tenho convicção de que veremos um espaço cada vez maior sendo ocupado pelos serviços RESTful e que esta passe a ser a forma número 1 de comunicação entre diferentes aplicações.

O formato Atom tem muito a ver com esse crescimento, pois além do formato ser excelente para manipular conteúdo web, o protocolo AtomPub é um belo blueprint de implementação REST. Sempre que eu estou tentando definir um protocolo de comunicação REST e fico um pouco em dúvida sobre a melhor forma de fazer alguma coisa, minha primeira referência é o AtomPub. Estudar como eles resolvem problemas comuns no desenvolvimento REST te dá uma visão muito boa das opções disponíveis. Você já começa de um ponto de partida muito bom, e fica bem mais fácil elaborar um protocolo conciso e coerente depois que você conhece o AtomPub.

A propósito, quem quiser conhecer mais sobre implementação de serviços REST, recomendo fortemente a Java Magazine de Abril. Um certo sujeito vai publicar um artigo prático bem interessante sobre implementação destes serviços 😉

Anúncios

RESTFox

fevereiro 26, 2008

Atenção, este blog foi migrado para: http://brunopereira.org

Eu tenho trabalhado bastante com web services REST ultimamente. Para testar meus serviços, a forma padrão que eu uso para testar é criar alguns testes unitários que montam as requisições e recebem as respostas com o commons-http-client.

O commons-http-client é perfeito para testes unitários, e para uso por uma aplicação. Para testar manualmente, entretanto, eu gostaria de algo mais prático. Pensando um pouco nas características dos testes que eu faço, um plugin do Firefox seria a ferramenta perfeita. Eu precisaria criar requisições HTTP com qualquer método (além de GET e POST) e especificar o corpo da requisição (onde for o caso), assim como alguns headers também.

O caso de uso principal deste plugin seria a criação de requisições GET, POST, PUT ou DELETE nas quais eu pudesse especificar os XMLs do corpo (aplicável apenas para POST e PUT) e pudesse conferir a resposta HTTP completa, incluindo todos os headers. Isso já seria uma facilidade enorme. Para refinar, deveria ser possível guardar alguns templates de XMLs de entrada. Um exemplo claro que me vem à cabeça é um template de XML no formato Atom, que poderia ser usado para requisições à Google Data API, entre diversos outros serviços que já utilizam o Atom como formato padrão de documentos.

Eu dei uma procurada boa e não achei nenhum plugin que fizesse nem uma parte disso que eu quero. Caso vocês conheçam alguma ferramenta do gênero (mesmo que não seja plugin do Firefox) por favor me avisem. Se eu não descobrir nenhuma ferramenta que ofereça isso ao menos de forma parcial, pretendo desenvolver eu mesmo esse plugin para o Firefox. Eu ainda nem comecei a fazer nada desse plugin, mas já gosto do nome RESTFox. Vamos ver se sai algo bacana daí… eu nunca desenvolvi plugins para o Firefox, mas me parece que este será o primeiro 🙂


Java annotations abuse

fevereiro 21, 2008

Atenção, este blog foi migrado para: http://brunopereira.org

I know Java annotations are a very controversial subject, and there are lots of different opinions regarding them.

In a general manner, i like annotations. Annotations placed on classes and methods are nice, they help a lot without much damage. A good example of well used annotations in my opinion is the Java Persistence API. It reduces a lot of the code you’d need to write and doesn’t polute things too much.

However, placing annotations inside method arguments, such as in JSR-311 (first place where i saw it) starts to really mess things up. Here’s an example of the use they propose:

@UriTemplate("widgets")
public class WidgetList {
@HttpMethod
@UriTemplate("offers")
WidgetList getDiscounted() {...}


@UriTemplate("{id}")
Widget findWidget(@UriParam("id") String id) {
return lookupWidget(id);
}
}

The @UriParam is the one that really bothers me here. I’m sure it must serve a good purpose for the JSR, and it probably makes some stuff easier. However, it’s unquestionable that annotating this much starts to polute the code beyond the acceptable limits. In such a short piece of code we saw 5 annotations.

I’m not saying we should go back to XML files. I really prefer annotations over XML when they are used over classes and methods, much like JPA does it. However, as many other things, annotations can be misused, and in this JSR 311 example, i think they misuse them. I just hope this trend doesn’t get stronger, because i think Java would get uglier with this. Just keep the simple annotations please 🙂


Velox – péssima qualidade de serviço

fevereiro 21, 2008

Atenção, este blog foi migrado para: http://brunopereira.org

Sou assinante do Velox já há uns 6 anos, e de uma maneira geral o serviço sempre foi bem razoável. Neste período, em alguns momentos ocorreram indisponibilidades eventuais, mas nada tão freqüente.

Entretanto, nos últimos 2 meses a qualidade do serviço do Velox está péssima, abaixo da crítica. Durante períodos prolongados ficamos sem conseguir conectar aqui em casa, e a conexão tem se mostrado muito instável. Todos os dias quando chego em casa tenho enfrentado dificuldades de conexão. Algumas vezes eu demoro para conseguir conectar. Outras vezes a conexão cai e eu demoro para conseguir conectar novamente. Ah, um detalhe… na maioria das vezes que a conexão cai, só consigo conectar novamente após desligar o modem ADSL por alguns minutos e ligar novamente.

Aqui em casa temos o Oi Conta Total 4, que custa caro dá direito ao Velox de 1 Mbps, telefone fixo com ligações locais ilimitadas e 4 linhas móveis com 1000 minutos de franquia mensal. Como é um pacotão só, não dá para definir a parcela do valor que vai para pagar o Velox. Mas de qualquer forma, em 2008 um plano de banda larga de 1 Mbps está longe de ser algo sofisticado. Já temos esta velocidade de acesso há cerca de 2 anos, e mesmo na época em que contratamos já existiam opções com maior velocidade. Estamos pagando caro por um serviço basicão e mesmo assim ele está sendo prestado de forma absurdamente ruim.

Não sei o que está acontecendo com o Velox para chegar em um nível tão baixo de qualidade. Moro a menos de 1 km de uma grande central digital da Telemar, onde teoricamente as condições de prestação do serviço deveriam estar entre as melhores do Rio de Janeiro. O que temos visto entretanto é que a operadora não tem a menor condição de cumprir com o que está vendendo, pois fica nítido que a qualidade do serviço fica criticamente baixa entre 20:00 e 00:00, quando há uma grande quantidade de usuários conectados. Ligar para a Central de Atendimento é pedir para se aborrecer. Já vieram técnicos da empresa aqui em casa 3 vezes esse ano e nada mudou.

Minha mãe está entrando com processo contra a Oi esta semana, pois já passamos do limite suportável de aborrecimentos. Para quem por acaso estiver lendo isso, a única coisa que posso fazer é recomendar que evitem o Velox, pois a coisa está feia. Não posso dizer se o Virtua é melhor, pois nunca tivemos aqui em casa. Entretanto, difícil ficar abaixo do patamar de qualidade do Velox hoje em dia!


Google Data API

fevereiro 21, 2008

Atenção, este blog foi migrado para: http://brunopereira.org

I’m currently using Google Data API at work. This API offers RESTful interfaces for several Google services, such as Calendar, Picasa, You Tube, Blogger, Google Documents, among others. There are also client libraries for Java, C# and Python, but these are actually tools to facilitate, rather than new interfaces. All client libraries access the RESTful interfaces, so by all acounts the API is RESTful.

What I’d like to comment is how easy it was for me the to get up to speed with the API. There are several pages explaining the API’s features, the URIs, their use of HTTP method, return types, etc. Their design is pretty much compliant to all REST best practices (although they do use some query string parameters ocasionally). Being very familiar with this kind of web services, most of what I did was looking and saying: “Ok , this is how i expected it to be”. And after less than one hour I was ready to begin using the API properly.

Worth noting is that there were no “Interface Document” to look at. Not anything similar to WSDL or any other IDL. What was there was just a simple and RESTful API that was pretty easy to use after you knew what the resources were and which operations they support. Several pages describing their protocol and the XML entities they use were enough for me to know how I was supposed to integrate with a reasonable amount of their services.

I don’t even want of to think of how would it be if they had WS-*. Just to read the WSDL documents would take me more time than to read all their RESTful documentation. There would be a lot of operations and messages described in their WSDLs, and it’d be a massive reading to get the grasp of the API.

Fortunately Google (the most powerful web company) is embracing a RESTful design and it should probably take many other companies with it. They’re also supporting the use of Atom and Atom Publishing Protocol, so many nice things should keep coming. Apache Abdera is already integrating Google Feed Server code, and hopefully we’ll be able to use Abdera for most of Google’s services.

Very very nice! By the way, I took a good look in the source code of Google Data API and it’s very well implemented. They have a very interesting approach to manipulate feeds and entries. It makes it very easy to model a lot of stuff using just feeds and entries. It was an inspiring code inspection and I’m thankful Google also embraces open source 🙂 These guys are good!


Java Magazine 54 – Meu primeiro artigo

fevereiro 14, 2008

Atenção, este blog foi migrado para: http://brunopereira.org

Java Magazine - Edição 54 - Fevereiro de 2008

Caros amigos, é com enorme satisfação que anuncio que esta semana chega às bancas a edição 54 da Java Magazine, na qual estou publicando o meu primeiro artigo.

No artigo desta edição, faço uma análise imparcial dos web services REST e web services WS-*, dando uma visão pragmática do nosso momento atual de implementação de web services.

Este é o primeiro do que eu espero que sejam muitos artigos meus publicados na revista, e pelo menos inicialmente a maioria deles será na área de web services. Espero que bastante gente leia o artigo e possivelmente dê opiniões sobre o mesmo. Torço para que vocês gostem das minhas publicações, vamos ver se eu levo jeito para a coisa 😉


Diversidade de tecnologias

fevereiro 11, 2008

Atenção, este blog foi migrado para: http://brunopereira.org

Eu tenho postado com alguma freqüência sobre o que vem acontecendo no desenvolvimento das tecnologias dos web services Restful.

Este fim de semana o James Snell implementou um adapter do Apache Abdera para o CouchDB. Este adapter permite que se consiga facilmente implementar um armazenamento de dados no formato Atom com uso de uma instância do CouchDB.

Como eu já mencionei anteriormente, o Abdera oferece uma API para manipulação de conteúdo no formato Atom e a realização de operações do Atom Publishing Protocol. Já o CouchDB é um banco de dados orientado a documentos que é escrito em Erlang e foi projetado para extrema escalabilidade e permite fácil instalação em servidores com múltiplos núcleos ou em clusters de máquinas.

Em vez de utilizar tabelas com colunas (como os bancos de dados relacionais), o CouchDB armazena os documentos em formato JSON e disponibiliza como interface uma API Restful, com clientes já implementados em várias linguagens, como Javascript, Java, PHP, Ruby e Python.

Acho que isto expressa muito bem o horizonte que vem se formando. Em vez de pilha de tecnologias e protocolos proprietários, temos diversas tecnologias e plataformas diferentes conseguindo se comunicar através de HTTP. Um projeto open source Java que manipula conteúdo Atom já disponibiliza com facilidade um mecanismo de integração com serviços REST que manipulam dados em formato JSON.

É impressão minha ou estamos de fato vendo rapidamente uma mudança radical de abordagem na vanguarda da tecnologia? A mesma IBM que antigamente dominava de forma absoluta todo o mercado de hardware e software com soluções proprietárias agora patrocina diversos projetos open source e mantém sua elite intelectual trabalhando nestes projetos.

Soluções open source estão liderando várias frentes de desenvolvimento e com isso rapidamente surgem integrações entre componentes feitos em diferentes linguagens e plataformas. O conhecimento não está mais guardado a 7 chaves, e sim discutido abertamente por uma comunidade que aceita qualquer um com capacidade para agregar idéias boas.

A criatividade e a iniciativa individual nunca tiveram tanto poder, e isto é fabuloso. Com isso, claro que a versatilidade e o conhecimento diversificado ficam muito valiosos.

Hum… maybe it’s time for me to fight my disgust for Javascript and start developing something nice including JSON 😉