Standards in specification of RESTful API's and why do it?

I have been looking for ways and standards to specify RESTful API's. Since then I have been with a lot of tabs opened in my web browser just to not loose the url's and interesting things I have found out there. So, I realized that I can maybe help someone else if I put all those url's I found in a blog post. So, then here I am.

Below is a list of links I have found and some thoughts about each of them.

• WADL (Web Application Description Language) reference: apigee uses WADL to generate a console to your API but it requires that you describe your API in WADL.
• Do WADL's serve any purpose?: Not just WADL, but does any API specification serve to any propose and which proposes?
• Swagger: Another way/language to describe your API and then you can generate a console for your API and clients in some languages (the python code that it generates is terrible)
• Guide to specify API in Swagger: It seems to be easier to write than WADL and I prefer to write JSON than a XML file.

In my current job I'm writing an micro-framework called Tapioca for help people to create API's using Tornado. I have decided to create this project because I didn't found anything similar to use with Tornado. In Django you can use Tastypie or Django-rest Framework. Tornado projects can be made in so far different ways than in Django because in Django you normally follow an common sense to create projects and the framework is used in all levels of the application, since the database access until the web interface. Using Tornado you are completely free to use anything to database access and you not tells the framework which are and how are your models.
The objective of Tapioca is to provide a common behaviour to manage resources as close as possible to the definition of your RESTful API. I'm trying to follow the best practices of creation of RESTful API's. Other objective is to provide a automatic API specification in WADL and Swagger - so, then you will be able to use the apigee console or generate your own console using Swagger-ui.
I am working right now to figure out a way to generate those metadata to generate the specifications about an API created using Tapioca. I will post soon about it and while I am woking you can track what I am doing in the project github.
I'm not a native english speaker so if you found anything that I wrote is incorrect. Please, tell me and I will correct it.

Finalmente entendi o PyPy

Olá pessoal, depois de muito tempo sem postar nada aqui estou voltando a escrever alguma coisa. Espero começar a escrever mais por aqui. Vou tentar.

Como muitos sabem, eu curto muito essa parte de implementação de compiladores e interpretadores e etc. E sempre que posso fico lendo coisas legais sobre este assunto. Recentemente Bernardo Heynemann me enviou um post de um cara que estava implementando sua própria linguagem. O autor (Laurence Tratt) percebeu que precisava melhorar ainda mais a performance dessa linguagem, porém escrever um JIT do zero é uma tarefa muito complicada e trabalhosa. Foi ai que Laurence Tratt se deparou com o PyPy e resolveu (depois de alguns testes e estudos) portar a implementação de sua linguagem para o PyPy e obteve ganhos de performance absurdos. Se quiser mais detalhes, é melhor ler o post. O que eu quero destacar aqui é que durante a leitura do post eu entendi, finalmente, o projeto PyPy.

Afinal o que é o PyPy?

Muitas pessoas tentaram me explicar alguns anos atrás, mas só agora que caiu a ficha. O PyPy tem como objetivo ser uma implementação alternativa mais rápida do interpretador da linguagem Python (versão 2.7.2) o CPython. Só que as pessoas sempre me vendiam o PyPy como a implementação de Python em Python. Eu nunca entendia isso direito e deixava pra lá. Até o belo dia em que eu li aquele post e parei para realmente entender. O PyPy (de forma bem abstrata) é um nome para dos projetos diferentes mas que sevem para solucionar um problema: criar uma implementação mais rápida da linguagem Python. São eles:

• RPython Toolchain - um projeto para implementação de linguagens dinâmicas que usa como DSL um subset da linguagem Python que é chamado de RPython. Seve para implementar interpretadores para qualquer linguagem de programação usando RPython. Essa implementação é usada para gerar código nativo (muito) otimizado.
• Uma implementação da linguagem Python - esta implementação é compatível com a versão 2.7.2 do CPython e este interpretador é escrito em RPython.

Devido a o nome PyPy se referir a estes "dois" projetos. Muita gente se confunde, e muito, sobre o que é o PyPy (assim como eu). O que eu achei mais interessante depois deste entendimento é que eu posso usar o RPython para implementar interpretadores para qualquer linguagem que eu quiser e com isso ganhar até um JIT de brinde para esta nova linguagem.

O que estou fazendo agora é estudando melhor o RPython para usar-lo em um projeto de linguagem de programação que quero fazer. Estou bastante motivado a fazer isso e espero postar resultados dessa brincadeira por aqui em breve. Para maiores dúvidas e detalhes sobre o PyPy a documentação pode ser encontrada aqui.