cph/rabl-oldSistema di templating Ruby per generare API JSON e XML, con una correzione per CVE-2014-4671. Supporta partial, ereditarietà e nodi personalizzati per una costruzione flessibile delle risposte API.
RABL (Ruby API Builder Language) è un sistema di templating Ruby per Rails e Padrino per generare JSON, XML, MessagePack, PList e BSON. Quando uso il metodo 'to_json' di ActiveRecord, mi ritrovo a desiderare una soluzione più espressiva e potente per generare API. Questo è particolarmente vero quando la rappresentazione JSON è complessa o non corrisponde allo schema esatto definito nel database.
In particolare, voglio facilmente:
Chiunque abbia provato il metodo 'to_json' usato in ActiveRecord per generare una risposta JSON ha sentito il dolore di questo approccio restrittivo. RABL è un sistema di templating generale creato per risolvere questi problemi affrontando la generazione di risposte API in un modo completamente nuovo.
Al cuore, RABL riguarda l'aderenza ai principi MVC delegando le rappresentazioni dei dati API al livello view della tua applicazione. Per una analisi delle idee sbagliate comuni su RABL, consulta la nostra guida Understanding RABL che può aiutare a chiarire eventuali confusioni su questo progetto.
v0.8.0 (rilasciata il 14 febbraio 2013) rimuove la dipendenza da multi_json e si basa su Oj (o JSON) come parser json. Semplifica il codice, rimuove una dipendenza ma potresti voler rimuovere qualsiasi riferimento a MultiJson.
v0.6.14 (rilasciata il 28 giugno 2012) richiede l'uso di render_views con RSpec per testare i template. Altrimenti, il controller passerà semplicemente attraverso il comando render come fa con i template ERB.
Installa RABL come gemma:``` gem install rabl
oppure aggiungi al tuo Gemfile:```ruby
# Gemfile
gem 'rabl'
# Also add either `oj` or `yajl-ruby` as the JSON parser
gem 'oj'
ed esegui bundle install per installare la dipendenza.
Se stai utilizzando Rails 2.3.8 (e successive), Rails 3.X o Padrino, RABL funziona senza configurazione.
Importante: Con Padrino, assicurati che il gem rabl sia elencato dopo il gem padrino nel tuo Gemfile, altrimenti Rabl non si registrerà correttamente come motore di template.
Con Sinatra, o qualsiasi altro framework basato su tilt, registra semplicemente:```ruby Rabl.register!
e RABL sarà inizializzato e pronto per l'uso. Per l'utilizzo con Sinatra, consulta la guida [Sinatra Usage](https://github.com/nesquena/rabl/wiki/Setup-for-Sinatra).
## Overview ##
Puoi utilizzare RABL per generare API basate su JSON e XML da qualsiasi oggetto Ruby. Con RABL, i dati sono tipicamente derivati principalmente dai modelli (indipendenti dall'ORM) e la rappresentazione dell'output dell'API è descritta all'interno di un template di vista usando un semplice DSL Ruby. Questo ti permette di mantenere i tuoi dati separati dal JSON o XML che desideri produrre.
Una volta installato RABL (come spiegato sopra), puoi costruire un template di vista RABL e poi renderizzare il template dalle tue applicazioni Sinatra, Padrino o Rails dal controller (o route) molto facilmente. Usando [Padrino](http://padrinorb.com) come esempio, supponendo di avere un modello `Post` pieno di post del blog, puoi renderizzare una rappresentazione API (sia JSON che XML) creando una route:```ruby
# app/app.rb
get "/posts", :provides => [:json, :xml] do
@user = current_user
@posts = Post.order("id DESC")
render "posts/index"
end
Quindi possiamo creare il seguente template RABL per esprimere l'output API di @posts:```ruby
collection @posts attributes :id, :title, :subject child(:user) { attributes :full_name } node(:read) { |post| post.read_by?(@user) }
Che produrrebbe il seguente JSON o XML quando si visita `http://localhost:3000/posts.json````js
[{ "post" :
{
"id" : 5, title: "...", subject: "...",
"user" : { full_name : "..." },
"read" : true
}
}]
Questa è una panoramica di base, ma c'è molto altro da vedere come partials, inheritance, custom nodes, ecc. Leggi i dettagli completi di RABL qui sotto.
RABL è pensato per richiedere poca o nessuna configurazione per funzionare. Questo è il caso nella maggior parte degli scenari, ma a seconda delle vostre esigenze potreste voler impostare le seguenti configurazioni globali nella vostra applicazione (questo blocco è completamente opzionale):```ruby
require 'rabl' Rabl.configure do |config|
end
Ogni opzione specifica un comportamento relativo all'output di RABL. Se `include_json_root` è disabilitato, viene rimosso il nodo radice per ogni oggetto radice nell'output, e `enable_json_callbacks` abilita il supporto per output di callback in stile 'jsonp' se la richiesta in entrata ha un parametro 'callback'.
Se `include_child_root` è impostato su false, gli oggetti figli nella risposta non includeranno per impostazione predefinita un nodo radice. Questo ti consente di ottimizzare ulteriormente la struttura della risposta desiderata.
Se `cache_engine` è impostato, dovresti assegnarlo a una classe con un metodo `fetch`. Vedi il [motore predefinito](https://github.com/nesquena/rabl/blob/master/lib/rabl/cache_engine.rb) per un esempio.
Se `perform_caching` è impostato su `true`, eseguirà la memorizzazione nella cache. Puoi ignorare questa opzione se stai usando Rails, è equivalente a `config.action_controller.perform_caching` di Rails.
Se `cache_sources` è impostato su `true`, le ricerche dei template verranno memorizzate nella cache per migliorare le prestazioni. La cache può essere resettata manualmente eseguendo `Rabl.reset_source_cache!` all'interno della tua applicazione.
Se `cache_all_output` è impostato su `true`, ogni template, incluso ogni singolo template utilizzato come parte di una collezione, verrà memorizzato nella cache separatamente. Inoltre, qualsiasi cosa all'interno di child, glue e partial verrà anch'essa memorizzata separatamente. Per memorizzare nella cache un singolo template, consulta la sezione intitolata 'Caching' più avanti.