cph/rabl-oldSystème de templating Ruby pour générer des APIs JSON et XML, avec un correctif pour CVE-2014-4671. Prend en charge les partiels, l'héritage et les nœuds personnalisés pour une construction flexible de réponses API.
RABL (Ruby API Builder Language) est un système de templates Ruby pour Rails et Padrino permettant de générer du JSON, XML, MessagePack, PList et BSON. Lorsque j'utilise la méthode 'to_json' d'ActiveRecord, je me retrouve à vouloir une solution plus expressive et plus puissante pour générer des API. Cela est particulièrement vrai lorsque la représentation JSON est complexe ou ne correspond pas exactement au schéma défini dans la base de données.
En particulier, je veux facilement :
Quiconque a essayé la méthode 'to_json' utilisée dans ActiveRecord pour générer une réponse JSON a ressenti la douleur de cette approche restrictive. RABL est un système de templates général créé pour résoudre ces problèmes en abordant la génération de réponses API d'une manière entièrement nouvelle.
Au cœur de RABL, il s'agit de respecter les principes MVC en déléguant les représentations des données API à la couche vue de votre application. Pour une analyse des idées fausses courantes sur RABL, consultez notre guide pour comprendre RABL qui peut aider à dissiper toute confusion sur ce projet.
v0.8.0 (publié le 14 février 2013) supprime la dépendance multi_json et s'appuie sur Oj (ou JSON) comme analyseur JSON. Simplifie le code, supprime une dépendance, mais vous souhaiterez peut-être supprimer toutes les références à MultiJson.
v0.6.14 (publié le 28 juin 2012) nécessite l'utilisation de render_views avec RSpec pour tester les templates. Sinon, le contrôleur transmettra simplement la commande render comme il le fait avec les templates ERB.
Installer RABL en tant que gem :``` gem install rabl
ou ajoutez à votre Gemfile:```ruby
# Gemfile
gem 'rabl'
# Also add either `oj` or `yajl-ruby` as the JSON parser
gem 'oj'
et exécutez bundle install pour installer la dépendance.
Si vous utilisez Rails 2.3.8 (et versions ultérieures), Rails 3.X ou Padrino, RABL fonctionne sans configuration.
Important : Avec Padrino, assurez-vous que la gem rabl est listée après la gem padrino dans votre Gemfile, sinon Rabl ne s'enregistrera pas correctement comme moteur de template.
Avec Sinatra, ou tout autre framework basé sur tilt, inscrivez-le simplement :```ruby Rabl.register!
et RABL sera initialisé et prêt à être utilisé. Pour une utilisation avec Sinatra, consultez le guide [Utilisation de Sinatra](https://github.com/nesquena/rabl/wiki/Setup-for-Sinatra).
## Aperçu ##
Vous pouvez utiliser RABL pour générer des API basées sur JSON et XML à partir de n'importe quel objet Ruby. Avec RABL, les données sont généralement dérivées principalement des modèles (indépendants de l'ORM) et la représentation de la sortie de l'API est décrite dans un template de vue utilisant un simple DSL Ruby. Cela vous permet de garder vos données séparées du JSON ou XML que vous souhaitez produire.
Une fois que vous avez installé RABL (expliqué ci-dessus), vous pouvez construire un template de vue RABL puis rendre le template depuis vos applications Sinatra, Padrino ou Rails depuis le contrôleur (ou la route) très facilement. En utilisant [Padrino](http://padrinorb.com) comme exemple, en supposant que vous avez un modèle `Post` rempli d'articles de blog, vous pouvez rendre une représentation API (à la fois JSON et XML) en créant une route :```ruby
# app/app.rb
get "/posts", :provides => [:json, :xml] do
@user = current_user
@posts = Post.order("id DESC")
render "posts/index"
end
Ensuite nous pouvons créer le modèle RABL suivant pour exprimer la sortie de l'API de @posts :```ruby
collection @posts attributes :id, :title, :subject child(:user) { attributes :full_name } node(:read) { |post| post.read_by?(@user) }
Ce qui produirait le JSON ou XML suivant lors de la visite de `http://localhost:3000/posts.json````js
[{ "post" :
{
"id" : 5, title: "...", subject: "...",
"user" : { full_name : "..." },
"read" : true
}
}]
Voici un aperçu de base, mais il y a bien plus à voir comme les partials, l'héritage, les nœuds personnalisés, etc. Lisez les détails complets de RABL ci-dessous.
RABL est conçu pour nécessiter peu ou pas de configuration pour fonctionner. C'est le cas dans la plupart des scénarios, mais selon vos besoins, vous pouvez définir les configurations globales suivantes dans votre application (ce bloc est entièrement facultatif) :```ruby
require 'rabl' Rabl.configure do |config|
end
Chaque option spécifie un comportement lié à la sortie de RABL. Si `include_json_root` est désactivé, cela supprime le
nœud racine de chaque objet racine dans la sortie, et `enable_json_callbacks` active la prise en charge du style de sortie « jsonp »
si la requête entrante possède un paramètre « callback ».
Si `include_child_root` est défini sur false, les objets enfants dans la réponse n'incluront pas
de nœud racine par défaut. Cela permet d'affiner davantage la structure de réponse souhaitée.
Si `cache_engine` est défini, vous devez l'affecter à une classe avec une méthode `fetch`. Voir le [moteur par défaut](https://github.com/nesquena/rabl/blob/master/lib/rabl/cache_engine.rb) pour un exemple.
Si `perform_caching` est défini sur `true`, la mise en cache sera effectuée. Vous
pouvez ignorer cette option si vous utilisez Rails, c'est la même chose que
`config.action_controller.perform_caching` de Rails.
Si `cache_sources` est défini sur `true`, les recherches de templates seront mises en cache pour des performances améliorées.
Le cache peut être réinitialisé manuellement en exécutant `Rabl.reset_source_cache!` dans votre application.