
Sistema de templating em Ruby para gerar APIs JSON e XML, com uma correção para CVE-2014-4671. Suporta partials, herança e nós personalizados para construção flexível de respostas de API.
RABL (Ruby API Builder Language) é um sistema de templating Ruby para Rails e Padrino para gerar JSON, XML, MessagePack, PList e BSON. Ao usar o método 'to_json' do ActiveRecord, encontro-me querendo uma solução mais expressiva e poderosa para gerar APIs. Isso é especialmente verdade quando a representação JSON é complexa ou não corresponde ao esquema exato definido no banco de dados.
Em particular, quero facilmente:
Qualquer pessoa que já tentou o método 'to_json' usado no ActiveRecord para gerar uma resposta JSON sentiu a dor dessa abordagem restritiva. RABL é um sistema de templating geral criado para resolver esses problemas ao abordar a geração de respostas de API de uma maneira inteiramente nova.
RABL no seu núcleo é sobre aderir aos princípios MVC ao delegar as representações dos dados da API para a camada de visão da sua aplicação. Para uma análise de equívocos comuns sobre o RABL, consulte nosso guia para entender o RABL que pode ajudar a esclarecer qualquer confusão sobre este projeto.
v0.8.0 (lançado em 14 de fevereiro de 2013) remove a dependência multi_json e depende de Oj (ou JSON) como o analisador JSON. Simplifica o código, remove uma dependência, mas você pode querer remover quaisquer referências ao MultiJson.
v0.6.14 (lançado em 28 de junho de 2012) exige o uso de render_views com RSpec para testar templates. Caso contrário, o controlador simplesmente passará o comando render como faz com templates ERB.
Instale o RABL como uma gem:``` gem install rabl
ou adicione ao seu Gemfile:```ruby
# Gemfile
gem 'rabl'
# Also add either `oj` or `yajl-ruby` as the JSON parser
gem 'oj'
e execute bundle install para instalar a dependência.
Se você estiver usando Rails 2.3.8 (e superior), Rails 3.X ou Padrino, o RABL funciona sem configuração.
Importante: Com Padrino, certifique-se de que a gem rabl está listada depois da gem padrino no seu Gemfile, caso contrário, o Rabl não se registrará corretamente como um mecanismo de template.
Com Sinatra, ou qualquer outro framework baseado em tilt, simplesmente registre:```ruby Rabl.register!
e o RABL será inicializado e estará pronto para uso. Para uso com Sinatra, consulte o guia [Uso com Sinatra](https://github.com/nesquena/rabl/wiki/Setup-for-Sinatra).
## Visão Geral ##
Você pode usar o RABL para gerar APIs baseadas em JSON e XML a partir de qualquer objeto ruby. Com o RABL, os dados geralmente são derivados principalmente de modelos (independente de ORM) e a representação da saída da API é descrita dentro de um template de visão usando um simples DSL ruby. Isso permite que você mantenha seus dados separados do JSON ou XML que deseja gerar.
Depois de instalar o RABL (explicado acima), você pode construir um template de visão RABL e então renderizar o template a partir de suas aplicações Sinatra, Padrino ou Rails a partir do controlador (ou rota) muito facilmente. Usando [Padrino](http://padrinorb.com) como exemplo, assumindo que você tem um modelo `Post` preenchido com posts de blog, você pode renderizar uma representação de API (tanto JSON quanto XML) criando uma rota:```ruby
# app/app.rb
get "/posts", :provides => [:json, :xml] do
@user = current_user
@posts = Post.order("id DESC")
render "posts/index"
end
Então podemos criar o seguinte modelo RABL para expressar a saída da API de @posts:```ruby
collection @posts attributes :id, :title, :subject child(:user) { attributes :full_name } node(:read) { |post| post.read_by?(@user) }
O que geraria o seguinte JSON ou XML ao visitar `http://localhost:3000/posts.json````js
[{ "post" :
{
"id" : 5, title: "...", subject: "...",
"user" : { full_name : "..." },
"read" : true
}
}]
Trata-se de uma visão geral básica, mas há muito mais para ver, como parciais, herança, nós personalizados, etc. Leia os detalhes completos do RABL abaixo.
O RABL foi projetado para exigir pouca ou nenhuma configuração para funcionar. Esse é o caso na maioria dos cenários, mas dependendo das suas necessidades, você pode querer definir as seguintes configurações globais na sua aplicação (este bloco é completamente opcional):```ruby
require 'rabl' Rabl.configure do |config|
end
Cada opção especifica um comportamento relacionado à saída do RABL. Se `include_json_root` estiver desabilitado, isso remove o nó raiz para cada objeto raiz na saída, e `enable_json_callbacks` habilita suporte para saída de callback estilo 'jsonp' se a requisição recebida tiver um parâmetro 'callback'.
Se `include_child_root` for definido como falso, os objetos filhos na resposta não incluirão um nó raiz por padrão. Isso permite ajustar ainda mais a estrutura de resposta desejada.
Se `cache_engine` for definido, você deve atribuí-lo a uma classe com um método `fetch`. Veja o [mecanismo padrão](https://github.com/nesquena/rabl/blob/master/lib/rabl/cache_engine.rb) para um exemplo.
Se `perform_caching` for definido como `true`, então ele realizará o cache. Você pode ignorar esta opção se estiver usando Rails, é o mesmo que `config.action_controller.perform_caching` do Rails.
Se `cache_sources` for definido como `true`, as buscas de templates serão armazenadas em cache para melhor desempenho. O cache pode ser redefinido manualmente executando `Rabl.reset_source_cache!` dentro da sua aplicação.
Se `cache_all_output` for definido como `true`, todo template, incluindo cada template individual usado como parte de uma coleção, será armazenado em cache separadamente. Além disso, qualquer coisa dentro de child, glue e partial também será armazenada em cache separadamente. Para armazenar em cache apenas um único template, veja a seção intitulada 'Caching' abaixo.