RESTful APIs com Dart

Já ouviu falar de Dart? É uma linguagem bem bacana, embora ainda ache ela um pouco “verbose”, criada pelo Google. A linguagem lembra um pouco Java, mas adiciona features que são extremamente interessantes e que facilitam substancialmente nossa vida. Alguns desenvolvedores torcem o nariz para Dart por sua semelhança com Java e Javascript, outros a adoram, exatamente por ter essa semelhança mas incluir features que o Java carece.

Qual meu lado? Eu acho Dart massa! Principalmente por eu ter programado em Java por tantos anos. Entretanto, Ruby ainda é minha linguagem favorita! Imbatível! 🙂 Mas, eu não vim aqui para exaltar nem Java, nem Ruby e nem Dart. Eu estou escrevendo esse post para tratar sobre três frameworks escritos em Dart que podem facilitar a vida de quem deseja criar uma API RESTful usando essa linguagem.

Algumas das vantagens de criar uma API com Dart é que a nuvem do Google está preparada para o Dart e a linguagem inclui features bem interessantes para isso. Até o momento, encontrei três ferramentas para essa tarefa: Redstone.dart, RPC (do Google) e Shelf Rest. São três boas ferramentas, mas, como veremos a seguir, carecem de algumas funcionalidades interessantes que encontramos em frameworks como o Grape, para Ruby.

Alerto que eu não fiz um estudo exaustivo sobre essas ferramentas. Fiz pequenos exemplos e tentei implementar algumas features que sempre busco em ferramentas como essas. É capaz de existirem outros problemas mas com os quais eu não me deparei. Isto pode ter acontecido porque meus exemplos eram simples, bem básicos e quando eu encontrava dois ou três problemas que, na minha humilde opinião, são falhas graves para a construção de APIs, eu parava de fuçar.

Antes de começarmos a falar sobre essas ferramentas, eu sugiro assistir o vídeo acima. Eu descobri essas ferramentas através desse vídeo. É extremamente indicado para quem quer começar a desenvolver APIs em Dart!

Redstone.dart

O Redstone.dart foi escrito por um brasileiro chamado Luiz Mineo. O Luiz esteve à frente do Redstone até a versão 0.5 mas não pôde continuar seu desenvolvimento e agora o Redstone está nas mãos de abnegados desenvolvedores que já estão trabalhando em melhorias e reformulações profundas. A nova versão, 0.6, já está em Beta e aparentemente, próxima de ser lançada.

A principal questão é que o Redstone não foi feito especificamente para criar APIs RESTful. Com ele você pode criar rotas e tratar essas rotas usando os principais métodos HTTP de forma muito, mas muito fácil mesmo! Eu criei uma API simples nele em 10 minutos! Mas, então, o que falta nele? Vamos enumerar:

  1. Não permite alterar dinamicamente o status code. Desta forma, você não consegue mudar de 200 para 201 em um PUT que cria um recurso. Eu já relatei uma issue no Issue Tracking deles e um dos desenvolvedores considerou a feature necessária. Ou seja, é provável que eles implementem isso no futuro. Embora eu esteja avaliando a possibilidade de mandar um Pull Request! 😛
  2. O Redstone não tem uma forma fácil de tratar a versão da sua API. Para APIs, isto é importantíssimo, pois APIs sempre evoluem e não dá para jogar a versão anterior fora e colocar uma nova de supetão.
  3. Respostas Parciais. Também não tem nenhum mecanismo que facilite construir respostas parciais. Isto teria que ser implementado “na mão”.
  4. Não retorna os status “padrão” para cada método HTTP. Por exemplo, é esperado que o método POST retorne o status 201 CREATED. O Redstone não retorna automaticamente o 201, no lugar, ele retorna 200. 

RPC

RPC, diferente do Redstone, foi feito para criar APIs RESTful. Esse era o objetivo quando criaram ele. O RPC foi criado pelo Google e foi a escolhida pelo cara do vídeo que postei no início do post. Mas, infelizmente, tem uma coisa que me irritou nela. O RPC inclui a versão da API na URI. Não encontrei outra forma. Eu prefiro, e acho mais elegante, tratar a versão no cabeçalho ACCEPT. Eu uso a URI apenas para endereçar recursos. Somente!

Sendo uma biblioteca feita essencialmente para construir APIs RESTful, eu esperava encontrar maior flexibilidade com relação a isso. Outro problema que encontrei foi a impossibilidade de alterar o status code dinamicamente. Procurei na documentação como fazer isso, mas não encontrei. Dei uma leve fuçada no código, mas também não encontrei.

Shelf RPC

Como o nome sugere, o Shelf Rest é um adendo ao Shelf para criar serviços RESTful. Esta foi a única ferramenta que eu não testei profundamente. Só dei uma fuçada na documentação, então, peço desculpas caso eu esteja falando merda aqui! 😛 Do que pude observar, ele carece de todos os problemas que citei para o RPC e o Redstone adicionado de mais um: não encontrei como criar rotas usando o método PATCH. Estranho, hein?

Outra coisa que achei bem estranha: eles definem anotações para os métodos HTTP: @Get, @Post, @Put e @Delete. Só que inventaram uma anotação @AddAll que está na mesma categoria das outras. Oi? Semanticamente, não faz o mínimo sentido, embora a funcionalidade pareça interessante.

Conclusão

Você deve estar se perguntando: maluco, você indicaria algum desses frameworks? Eu sou meio xiita nesse negócio de APIs REST, então, tenderia a dizer não. Mas, eu acredito que é possível sim criar boas APIs RESTful usando o Redstone. Pareceu a biblioteca mais promissora e com maior flexibilidade. Eles tem um mecanismo de plugin que achei interessante, pois dá para, por exemplo, criar um mecanismo para retornar Partial Responses.

Ou seja, até aqui eu indicaria o Redstone. A outra pergunta que me fariam é: você acha que Dart está pronto para construir APIs RESTful? Minha resposta é que a linguagem está sim. Ainda não temos um framework tão interessante como é o Grape em Ruby. Uma coisa não invalida a outra. Dart é sim interessante para essa tarefa, mas ainda precisamos de ferramentas mais adaptadas para isto. Então, vamos construir uma? Vamos ajudar o pessoal do Redstone? Ou criar um plugin lá?

Eu vou! 😛

Sentiment Analysis – Parte 1

Você sabe o que é uma Análise de Sentimentos? Não, cara! Não estou falando sobre Freud ou Psicanálise. Imagine que você acabou de lançar seu produto, fez uma baita campanha de marketing e agora quer saber o que as pessoas acharam sobre ele. O que você faria? Pode contratar uma empresa para ir nas ruas coletar a opinião das pessoas. Pode também pedir para esta mesma empresa pedir a opinião dos consumidores através de pesquisas pela internet ou telefone. Mas e se você pudesse analisar as redes sociais e automaticamente detectar o que as pessoas estão achando? Isso, sem enquetes, sem pesquisas de opinião. Simplesmente analisando o que elas escrevem e descobrindo, a partir daí, o que elas acham sobre seus produtos e serviços. Genial, não?

E saiba que isso não é magia. Não é impossível. Aliás, é uma área que está fervendo ultimamente. Aliás, você encontrará diversas startups que estão trabalhando nisso. Até mesmo a IBM entrou na jogada e fez um aplicativo neste sentido para a Seleção Brasileira. Para você começar a entender sobre o que estou falando, sugiro inicialmente dar uma lida em um artigo da Communications of the ACM, que é gratuito. Basta se cadastrar e baixar a versão de Abril de 2013. É um artigo técnico, mas a parte inicial dá uma ideia bem legal sobre o assunto. A parte final também, onde eles exploram as áreas de aplicação.

Outro artigo bem legal sobre o assunto, embora também um pouco técnico, é esse aqui. Já este artigo aqui é mais light e mais fácil de ser entendido (e em português)Certo, mas por que estou escrevendo um post exclusivamente sobre esse assunto? Primeiro, é um assunto que me chama a atenção. Segundo, estou fazendo uma breve pesquisa sobre a aplicabilidade desse assunto dentro do Serpro, terceiro… terceiro… esqueci. Bom, mas a questão é que eu quero compartilhar com vocês o que venho aprendendo sobre o assunto, incluindo exemplos práticos. E além de ler muitos artigos sobre este assunto, eu também pesquisei ferramentas.

Caso você pesquise sobre ferramentas para Análise de Sentimentos no Google, não é de se espantar que uma das primeiras ferramentas que aparecem na pesquisa é a Google Prediction API. Mas ela não é a única na jogada. Temos também a Semantria, Datumbox, AlchemyAPI e muitas outras. Então, vamos fazer assim: você dá uma estudada sobre esse assunto, mesmo que superficialmente, e em uma sequência de posts, eu vou tratar sobre esse assunto. Vamos começar com um exemplo de aplicação rodando na Google Prediction API? Não? Então, deixe de pressa e aguarde os artigos falando sobre a Semantria, Datumbox e etc! Ah! Cadê o link para o próximo artigo? Calma, já está no forno!

AdMob vale a pena?

Já pensou em colocar propaganda em seus aplicativos Android? Se sim, já deve saber que existe o AdMob, do Google. Basta você fazer sua conta, pegar um arquivo .jar, colocar na sua aplicação, criar uma área na aplicação para exibir as propagandas e pronto. Mas o AdMob não é exclusividade do Android. Também pode ser usado em BlackBerry e iOS. Eu resolvi fazer um teste com ele. Primeiro, eu comecei vendendo minhas duas aplicações: EncomendaZ e BrasileirãoZ. Depois, resolvi testar se valeria a pena colocar AdMob. Vamos para as conclusões deste teste.

Já me perguntaram várias vezes o que vale mais a pena, se é vender ou colocar propaganda. Espero ter dado a resposta ao final deste post. Caso você queira uma resposta direta, na cara, sem frescura e está com preguiça de ler o restante do post, então, é… depende, cara pálida. Deixe de preguiça e leia até o final, seu zé ruela. Vamos entender o contexto da coisa. Eu coloquei duas aplicações com AdMob. Uma valeria a pena ter as propagandas. A outra, não. A que valeria seria o BrasileirãoZ, mas ainda assim não tenho certeza absoluta. A que não valeria é o EncomendaZ.

Vamos entender a situação agora. O AdMob só vale a pena para aplicativos “Top Sellers” e de grande uso diário. Somente para eles. O retorno é baixo e você acaba conseguindo em um mês o dinheiro que você conseguiria em 1 ano de AdMob. Exemplo disto? Vamos lá. Eu vendi 30 licenças do EncomendaZ pela Android Market. São 30 dólares acumulados. Contudo, não consegui ainda nem 2 dólares com as propagandas oriundas dele após mais de 3 meses. Entendeu o contexto? O EncomendaZ é um aplicativo muito específico. Tem cerca de 600 downloads após quase 1 ano de publicado. E 600 pessoas usando é muito pouco. E, claro, não são 600 pessoas usando direto. O que posso saber é que 600 baixaram, mas não saber se tem uso constante. Acredito que destas 600, talvez umas 100 usem constantemente.

Já o BrasileirãoZ leva vantagem. O brasileiro adora futebol e certamente é um aplicativo de uso constante. O cara quer sempre saber como anda seu time, classificação e etc. E isto se comprovou na prática. O BrasileirãoZ corresponde a mais de 90% do total de 13 dólares que arrecadei usando o AdMob. Mas ainda é pouco. Ele tem cerca de 2200 downloads atualmente e, aparentemente, um uso constante. Contudo, ainda arrecadei mais vendendo ele do que com AdMob. Foram 17 doletas vendendo e cerca de 10 dólares vindos de propaganda.

Há algo mais que você precisa pesar: o AdMob deixa sua aplicação feia, rouba espaço da tela e é chato. É igual a você entrar em uma página cheia de AdSense e que dá vontade de fechar imediatamente. Então, se vai colocar propaganda, faça com cuidado e pense bem. Vale a pena abusar seu usuário com essa propaganda mesmo? Bom, vou deixar aqui minha dica se você coloca ou não essa maldita propaganda… se bem que dica de maluco vale nada. Mas vou dizer ela mesmo assim.

Acredito que um plano melhor seja criar uma versão free com propaganda e outra paga sem propagandas e talvez mais opções. Principalmente se sua aplicação é muito específica e tende a não ser de uso constante. E essa dica, eu mesmo tentarei seguir nas minhas próximas aplicações. Uma aplicação somente free e com propaganda vale a pena para Angry Birds e por aí vai. Acho muito melhor você mesclar os dois mundos. Você tende a ganhar dos dois lados usando esta tática. Caso o cara seja mão de vaca e use sempre a free, ganha na propaganda. Caso sua aplicação seja boa mesmo e a galera passe a comprar, melhor ainda. 🙂