Top Related Projects
Jbuilder: generate JSON objects with a Builder-style DSL
A fast JSON:API serializer for Ruby (fork of Netflix/fast_jsonapi)
No Longer Maintained - A lightning fast JSON:API serializer for Ruby Objects.
Quick Overview
RABL (Ruby API Builder Language) is a Ruby library that provides a domain-specific language (DSL) for defining API responses. It allows developers to easily create JSON, XML, or custom data formats for their API endpoints, making it easier to manage and maintain API responses.
Pros
- Simplifies API Response Definition: RABL provides a concise and expressive DSL for defining API responses, reducing the amount of boilerplate code required.
- Flexible Data Formatting: RABL supports multiple data formats, including JSON, XML, and custom formats, allowing developers to choose the most appropriate format for their API.
- Efficient Data Rendering: RABL efficiently renders data, reducing the overhead of generating API responses.
- Extensibility: RABL can be extended with custom view helpers and partials, making it easy to integrate with existing codebases.
Cons
- Learning Curve: The RABL DSL may have a steeper learning curve compared to more traditional approaches to API response generation.
- Dependency on Ruby: RABL is a Ruby-specific library, which may limit its adoption in non-Ruby environments.
- Potential Performance Overhead: Depending on the complexity of the API responses, RABL may introduce some performance overhead compared to more lightweight approaches.
- Limited Tooling: The RABL ecosystem may have fewer third-party tools and integrations compared to more widely-used API response generation libraries.
Code Examples
Here are a few examples of how to use RABL:
Defining a Simple API Response
# app/views/users/show.json.rabl
object @user
attributes :id, :name, :email
This RABL template defines a simple API response for a user object, including the id
, name
, and email
attributes.
Nested Attributes and Associations
# app/views/users/show.json.rabl
object @user
attributes :id, :name, :email
child :posts do
attributes :id, :title, :body
end
This RABL template includes the user's associated posts, with each post's id
, title
, and body
attributes.
Conditional Attributes and Customization
# app/views/users/show.json.rabl
object @user
attributes :id, :name, :email
attribute :admin?, as: :is_admin
node(:created_at) { |user| user.created_at.to_s }
This RABL template includes a custom attribute is_admin
that is only included if the user is an admin. It also customizes the created_at
attribute to be rendered as a string.
Getting Started
To get started with RABL, you can follow these steps:
-
Add the RABL gem to your Gemfile:
gem 'rabl'
-
Run
bundle install
to install the gem. -
Create a RABL template file in your application's
app/views
directory. For example,app/views/users/show.json.rabl
:object @user attributes :id, :name, :email
-
In your controller action, assign the object you want to render to the
@user
instance variable:def show @user = User.find(params[:id]) render 'users/show' end
-
RABL will automatically render the JSON response based on the defined template.
That's the basic setup to get started with RABL. You can further customize the templates, add nested attributes, and leverage RABL's advanced features as needed for your API requirements.
Competitor Comparisons
Jbuilder: generate JSON objects with a Builder-style DSL
Pros of Jbuilder
- Integrated with Rails, providing seamless compatibility and performance optimizations
- Simple and intuitive syntax for creating JSON structures
- Supports partial rendering and caching out of the box
Cons of Jbuilder
- Less flexible for complex JSON structures compared to RABL
- Limited support for XML or other formats besides JSON
- Steeper learning curve for developers not familiar with Rails conventions
Code Comparison
RABL:
collection @posts
attributes :id, :title, :content
child(:author) { attributes :name }
node(:comments_count) { |post| post.comments.count }
Jbuilder:
json.array! @posts do |post|
json.extract! post, :id, :title, :content
json.author do
json.name post.author.name
end
json.comments_count post.comments.count
end
Both RABL and Jbuilder are popular choices for generating JSON responses in Ruby applications. RABL offers more flexibility and format options, while Jbuilder provides tighter Rails integration and a simpler syntax for straightforward JSON structures. The choice between them often depends on the specific project requirements and developer preferences.
A fast JSON:API serializer for Ruby (fork of Netflix/fast_jsonapi)
Pros of jsonapi-serializer
- Follows JSON:API specification, ensuring standardized output
- Supports relationship serialization out of the box
- Offers better performance for large datasets
Cons of jsonapi-serializer
- Less flexible in terms of output customization
- Steeper learning curve for developers unfamiliar with JSON:API
Code Comparison
jsonapi-serializer:
class UserSerializer
include JSONAPI::Serializer
attributes :name, :email
has_many :posts
end
rabl:
object @user
attributes :name, :email
child :posts do
extends "posts/index"
end
Key Differences
- Syntax: jsonapi-serializer uses a class-based approach, while rabl uses a DSL-like syntax.
- Output format: jsonapi-serializer strictly adheres to JSON:API, while rabl allows for more customized output.
- Performance: jsonapi-serializer generally offers better performance, especially for larger datasets.
- Flexibility: rabl provides more flexibility in terms of output structure and customization.
- Learning curve: rabl may be easier to pick up for beginners, while jsonapi-serializer requires understanding of the JSON:API specification.
Use Cases
- Choose jsonapi-serializer when building APIs that need to comply with the JSON:API specification or when dealing with large datasets.
- Opt for rabl when you need more flexibility in output customization or when working on projects that don't require strict adherence to JSON:API.
No Longer Maintained - A lightning fast JSON:API serializer for Ruby Objects.
Pros of fast_jsonapi
- Significantly faster performance, especially for large datasets
- Built-in support for JSON:API specification
- Simpler DSL for defining serializers
Cons of fast_jsonapi
- Less flexible than RABL for complex custom serialization needs
- Requires more setup and configuration for non-standard use cases
- Limited support for older Ruby versions
Code Comparison
RABL:
collection @posts
attributes :id, :title, :content
child(:author) { attributes :name }
node(:custom_field) { |post| post.calculate_something }
fast_jsonapi:
class PostSerializer
include FastJsonapi::ObjectSerializer
attributes :id, :title, :content
belongs_to :author
attribute :custom_field do |post|
post.calculate_something
end
end
Both libraries allow for serializing ActiveRecord objects into JSON, but fast_jsonapi uses a more object-oriented approach with serializer classes. RABL offers a more template-like syntax, which can be more intuitive for simple cases but may become harder to maintain for complex serializations. fast_jsonapi's performance advantages come at the cost of some flexibility, while RABL provides more fine-grained control over the output structure at the expense of speed.
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual CopilotREADME
RABL
RABL (Ruby API Builder Language) is a Rails and Padrino ruby templating system for generating JSON, XML, MessagePack, PList and BSON. When using the ActiveRecord 'to_json' method, I find myself wanting a more expressive and powerful solution for generating APIs. This is especially true when the JSON representation is complex or doesn't match the exact schema defined within the database.
In particular, I want to easily:
- Create arbitrary nodes named based on combining data in an object
- Pass arguments to methods and store the result as a child node
- Render partial templates and inherit to reduce code duplication
- Rename or alias attributes to change the name from the model
- Append attributes from a child into a parent node
- Include nodes only if a certain condition has been met
Anyone who has tried the 'to_json' method used in ActiveRecord for generating a JSON response has felt the pain of this restrictive approach. RABL is a general templating system created to solve these problems by approaching API response generation in an entirely new way.
RABL at the core is all about adhering to MVC principles by deferring API data representations to the view layer of your application. For a breakdown of common misconceptions about RABL, please check out our guide to understanding RABL which can help clear up any confusion about this project.
Breaking Changes
-
v0.9.0 (released Oct 14, 2013) changes the default node name for certain associations especially around STI models. You might want to verify for any breakages as a result and be more explicit by specifying an alias i.e
@users => :users
-
v0.8.0 (released Feb 14, 2013) removes multi_json dependency and relies on Oj (or JSON) as the json parser. Simplifies code, removes a dependency but you might want to remove any references to MultiJson.
-
v0.6.14 (released June 28, 2012) requires the use of render_views with RSpec to test templates. Otherwise, the controller will simply pass through the render command as it does with ERB templates.
Installation
Install RABL as a gem:
gem install rabl
or add to your Gemfile:
# Gemfile
gem 'rabl'
# Also add either `oj` or `yajl-ruby` as the JSON parser
# If using `oj`, Rabl will set the mode to :compat
gem 'oj'
and run bundle install
to install the dependency.
If you are using Rails 2.3.8 (and up), Rails 3.X or Padrino, RABL works without configuration.
Important: With Padrino, be sure that the rabl gem is listed after the padrino gem in your Gemfile, otherwise Rabl will not register properly as a template engine.
With Sinatra, or any other tilt-based framework, simply register:
Rabl.register!
and RABL will be initialized and ready for use. For usage with Sinatra, check out the Sinatra Usage guide.
Overview
You can use RABL to generate JSON and XML based APIs from any ruby object. With RABL, the data typically is derived primarily from models (ORM-agnostic) and the representation of the API output is described within a view template using a simple ruby DSL. This allows you to keep your data separated from the JSON or XML you wish to output.
Once you have installed RABL (explained above), you can construct a RABL view template and then render the template
from your Sinatra, Padrino or Rails applications from the controller (or route) very easily. Using Padrino as an
example, assuming you have a Post
model filled with blog posts, you can render an API representation (both JSON and XML) by creating a route:
# app/app.rb
get "/posts", :provides => [:json, :xml] do
@user = current_user
@posts = Post.order("id DESC")
render "posts/index"
end
Then we can create the following RABL template to express the API output of @posts
:
# app/views/posts/index.rabl
collection @posts
attributes :id, :title, :subject
child(:user) { attributes :full_name }
node(:read) { |post| post.read_by?(@user) }
Which would output the following JSON or XML when visiting http://localhost:3000/posts.json
[{ "post" :
{
"id" : 5, "title": "...", "subject": "...",
"user" : { "full_name" : "..." },
"read" : true
}
}]
That's a basic overview but there is a lot more to see such as partials, inheritance, custom nodes, etc. Read the full details of RABL below.
Configuration
RABL is intended to require little to no configuration to get working. This is the case in most scenarios, but depending on your needs you may want to set the following global configurations in your application (this block is completely optional):
# config/initializers/rabl_init.rb
require 'rabl'
Rabl.configure do |config|
# Commented as these are defaults
# config.cache_all_output = false
# config.cache_sources = Rails.env != 'development' # Defaults to false
# config.cache_engine = Rabl::CacheEngine.new # Defaults to Rails cache
# config.perform_caching = false
# config.escape_all_output = false
# config.json_engine = nil # Class with #dump class method (defaults JSON)
# config.msgpack_engine = nil # Defaults to ::MessagePack
# config.bson_engine = nil # Defaults to ::BSON
# config.plist_engine = nil # Defaults to ::Plist::Emit
# config.include_json_root = true
# config.include_msgpack_root = true
# config.include_bson_root = true
# config.include_plist_root = true
# config.include_xml_root = false
# config.include_child_root = true
# config.enable_json_callbacks = false
# config.xml_options = { :dasherize => true, :skip_types => false }
# config.view_paths = []
# config.raise_on_missing_attribute = true # Defaults to false
# config.replace_nil_values_with_empty_strings = true # Defaults to false
# config.replace_empty_string_values_with_nil_values = true # Defaults to false
# config.exclude_nil_values = true # Defaults to false
# config.exclude_empty_values_in_collections = true # Defaults to false
# config.camelize_keys = :upper # Defaults to false
end
Each option specifies behavior related to RABL's output.
If include_json_root
is disabled that removes the root node for each root object in the output, and enable_json_callbacks
enables support for 'jsonp' style callback
output if the incoming request has a 'callback' parameter.
If include_child_root
is set to false then child objects in the response will not include
a root node by default. This allows you to further fine-tune your desired response structure.
If cache_engine
is set, you should assign it to a class with a fetch
method. See the default engine for an example.
If perform_caching
is set to true
then it will perform caching. You
can ignore this option if you are using Rails, it's same to Rails
config.action_controller.perform_caching
If cache_sources
is set to true
, template lookups will be cached for improved performance.
The cache can be reset manually by running Rabl.reset_source_cache!
within your application.
If cache_all_output
is set to true
, every template including each individual template used as part of a collection will be cached separately.
Additionally, anything within child, glue and partial will also be cached separately.
To cache just a single template, see the section titled 'Caching' below.
If escape_all_output
is set to true
and ActiveSupport is available, attribute output will be escaped using ERB::Util.html_escape.
If view_paths
is set to a path, this view path will be checked for every rabl template within your application.
Add to this path especially when including Rabl in an engine and using view paths within a another Rails app.
If raise_on_missing_attribute
is set to true
, a RuntimeError will be raised whenever Rabl
attempts to render an attribute that does not exist. Otherwise, the attribute will simply be omitted.
Setting this to true during development may help increase the robustness of your code, but using true
in
production code is not recommended.
If replace_nil_values_with_empty_strings
is set to true
, all values that are nil
and would normally be displayed as null
in the response are converted to empty strings.
If exclude_nil_values
is set to true
, all values that are nil
and would normally be displayed as null
in the response are not included in the response.
if exclude_empty_values_in_collections
is set to true
, all values in a collection that are {}
and would normally be displayed as {}
in the response are not included in the response.
If camelize_keys
is set to true
, all object keys will be converted to camel case. By default the first character will be lower case. The value can be set to :upper
to set the first character to upper case.
If you wish to use oj as the primary JSON encoding engine simply add that to your Gemfile:
# Gemfile
gem 'oj'
and RABL will use that engine automatically for encoding your JSON responses.
Set your own custom json_engine which define a dump
or encode
method for converting to JSON from ruby data:
config.json_engine = ActiveSupport::JSON
Format Configuration
RABL supports configuration for MessagePack, BSON, and Plist. Check the Format Configuration page for more details.
Usage
Object Assignment
To declare the data object for use in the template:
# app/views/users/show.json.rabl
object @user
or specify an alias for the object:
object @user => :person
# => { "person" : { ... } }
or pass a collection of objects:
collection @users
# => [ { "user" : { ... } } ]
or specify a root node label for the collection:
collection @users => :people
# => { "people" : [ { "person" : { ... } } ] }
or even specify both the child and root labels for a collection:
collection @users, :root => "people", :object_root => "user"
# => { "people" : [ { "user" : { ... } } ] }
and this will be used as the default data for the rendering, or disable the object root explicitly:
collection @users, :root => "people", :object_root => false
# => { "people" : [ { ... }, { ... } ] }
There can also be odd cases where the root-level of the response doesn't map directly to any object:
object false
node(:some_count) { |m| @user.posts.count }
child(@user) { attribute :name }
In those cases, object can be assigned to 'false' and nodes can be constructed free-form.
Attributes
Basic usage of the templater to define a few simple attributes for the response:
# app/views/users/show.json.rabl
attributes :id, :foo, :bar
or use with aliased attributes:
# Take the value of model attribute `foo` and name the node `bar`
attribute :foo => :bar
# => { bar : 5 }
or even multiple aliased attributes:
attributes :bar => :baz, :dog => :animal
# => # { baz : <bar value>, animal : <dog value> }
or show attributes only if a condition is true:
# m is the object being rendered, also supports :unless
attributes :foo, :bar, :if => lambda { |m| m.condition? }
Named and aliased attributes can not be combined on the same line. This currently does not work:
attributes :foo, :bar => :baz # throws exception
in such cases, you need to specify attributes twice.
attributes :foo
attributes :bar => :baz
Child Nodes
Often a response requires including nested information from data associated with the parent model:
child :address do
attributes :street, :city, :zip, :state
end
You can also disable object root for child node:
child :posts, :object_root => false do
attributes :id, :title
end
You can also add child nodes from an arbitrary data source:
child @posts => :foobar do
attributes :id, :title
end
or use model associations with an alias:
# Renders all the 'posts' association
# from the model into a node called 'foobar'
child :posts => :foobar do
attributes :id, :title
end
You can also pass in the current object:
object @user
child :posts do |user|
attribute :title unless user.suspended?
end
Gluing Attributes
You can also append child attributes back to the root node:
# Appends post_id and post_name to parent json object
glue @post do
attributes :id => :post_id, :name => :post_name
end
Use glue to add additional attributes to the parent object.
You can also pass in the current object:
object @user
glue(@post) {|user| attribute :title if user.active? }
Custom Nodes
This will generate a json response based on the result of the node
block:
# app/views/users/show.json.rabl
node :full_name do |u|
u.first_name + " " + u.last_name
end
or don't pass a name and have the node block merged into the response:
node do |u|
{ :full_name => u.first_name + " " + u.last_name }
# => { full_name : "Bob Johnson" }
end
You can use custom nodes like these to create flexible representations of a value utilizing all the data from the model.
Partials
Often you need to access other data objects in order to construct custom nodes in more complex associations. You can get access to the rabl representation of another data object by rendering a RABL partial:
node :location do
{ :city => @city, :address => partial("users/address", :object => @address) }
end
or even access an object associated with the parent model:
node :location do |m|
{ :city => m.city, :address => partial("users/address", :object => m.address) }
end
You can use this method to construct arbitrarily complex nodes for your APIs. Note that you need to have RABL templates defined for each of the objects you wish to construct representations for in this manner.
Inheritance
Another common issue of many template builders is unnecessary code redundancy. Typically many representations of an object across multiple endpoints share common attributes or nodes. The nodes for a 'post' object are probably the same or similar in most references throughout the various endpoints.
RABL has the ability to extend other "base" rabl templates and additional attributes:
# app/views/users/advanced.json.rabl
extends "users/base" # another RABL template in "app/views/users/base.json.rabl"
node :can_drink do |m|
m.age > 21
end
You can also extend other rabl templates while constructing child nodes to reduce duplication:
# app/views/users/show.json.rabl
child @address do
extends "address/item"
end
Using partials and inheritance can significantly reduce code duplication in your templates.
You can see more examples on the Reusing Templates wiki page.
Passing Locals in Partials
You can pass an arbitrary set of locals when rendering partials or extending templates.
For example, if we want to show on posts/:id.json
any information regarding particular post and associated comments
but in other cases we want to hide those comments. We can use locals to do this:
# app/views/posts/index.json.rabl
collection @posts
extends('posts/show', :locals => { :hide_comments => true })
# or using partial instead of extends
# node(false) { |post| partial('posts/show', :object => :post, :locals => { :hide_comments => true })}
and then access locals in the sub-template:
# app/views/posts/show.json.rabl
object @post
attributes :id, :title, :body, :created_at
node(:comments) { |post| post.comments } unless locals[:hide_comments]
This can be useful as an advanced tool when extending or rendering partials.
Conditions
You can provide conditions to all kinds of nodes, attributes, extends, etc. which includes a given element only if the specified condition is true.
collection @posts
# m is the object being rendered, also supports :unless
node(:coolness, :if => lambda { |m| m.coolness > 5 }) do |m|
m.coolness
end
Because attributes take conditional options as well, we could simplify the example with:
collection @posts
# m is the object being rendered, also supports :unless
attribute(:coolness, :if => lambda { |m| m.coolness > 5 })
The value for the :if
and :unless
options may be a simple Boolean
, Proc
or a Symbol
. If it is a Symbol
and the specific @object
responds to its, the method will be called. Thus the example above can be rewritten as:
class Post
def cool?
coolness > 5
end
end
and then:
collection @posts
attribute :coolness, if: :cool?
Using conditions allows for easy control over when certain elements render.
Template Scope
In RABL, you have access to everything you need to build an API response. Each RABL template has full access to the controllers instance variables as well as all view helpers and routing urls.
# app/some/template.rabl
object @post
# Access instance variables
child(@user => :user) { ... }
# or Rails helpers
node(:formatted_body) { |post| simple_format(post.body) }
There should be no problem fetching the appropriate data to construct a response.
Deep Nesting
In APIs, you can often need to construct 2nd or 3rd level nodes. Let's suppose we have a 'quiz' model that has many 'questions' and then each question has many 'answers'. We can display this hierarchy in RABL quite easily:
# app/views/quizzes/show.json.rabl
object @quiz
attribute :title
child :questions do
attribute :caption
child :answers do
# Use inheritance to reduce duplication
extends "answers/item"
end
end
This will display the quiz object with nested questions and answers as you would expect with a quiz node, and embedded questions and answers. Note that RABL can be nested arbitrarily deep within child nodes to allow for these representations to be defined.
Caching
RABL has built-in caching support for templates leveraging fragment caching strategies. Note that caching is currently only available for Rails but support for other frameworks is planned in a future release. Simplest caching usage is:
# app/views/users/show.json.rabl
object @quiz
cache @quiz # key = rabl/quiz/[cache_key]
attribute :title
Caching can significantly speed up the rendering of RABL templates in production and is strongly recommended when possible. For more a more detailed look at caching, check out the Caching guide on the wiki.
Rendering Templates Directly
There are situations where an application requires RABL templates to be rendered outside
a traditional view context. For instance, to render RABL within a Rake task or to create
message queue payloads. For this case, Rabl.render
can be used as show below:
Rabl.render(object, template, :view_path => 'app/views', :format => :json) #=> "{...json...}"
You can use convenience methods on Rabl::Renderer
to render the objects as well:
Rabl::Renderer.json(@post, 'posts/show')
Rabl::Renderer.xml(@post, 'posts/show')
These methods allow RABL to be used for arbitrary conversions of an object into a desired format.
Rabl::Renderer.new('posts/show', @post, :view_path => 'app/views', :format => 'hash').render
You can also pass in other instance variables to be used in your template as:
Rabl::Renderer.new('posts/show', @post, :locals => { :custom_title => "Hello world!" })
Then, in your template, you can use locals[:custom_title]
as:
attribute :content
node(:title) { locals[:custom_title] }
Content Type Headers
Currently in RABL, the content-type of your response is not set automatically. This is because RABL is intended to work for any Rack-based framework and as agnostic to format as possible. Check this issue for more details, and if you have any ideas or patches please let me know.
In the meantime, be sure to set the proper content-types if needed. This is usually pretty simple in both Rails and Padrino. I recommend a before_filter on that controller or directly specified in an action.
Resources
There are many resources available relating to RABL including the RABL Wiki, and many tutorials and guides detailed below. You can check out the RABL Site as well.
Advanced Usage
Links to resources for advanced usage:
- Managing Complexity
- Production Optimizations
- Grape Integration
- Rendering JSON for a tree structure using RABL
- Layouts (erb, haml and rabl) in RABL
- Backbone or Ember.js Integration
- RABL with Rails Engines
Please add your own usages and let me know so we can add them here! Also be sure to check out the RABL Wiki for other usages.
Tutorials
Tutorials can always be helpful when first getting started:
- Railscasts #322 - Ryan Bates explains RABL
- BackboneRails - Great screencasts by Brian Mann
- http://blog.joshsoftware.com/2011/12/23/designing-rails-api-using-rabl-and-devise/
- http://tech.favoritemedium.com/2011/06/using-rabl-in-rails-json-web-api.html
- http://seesparkbox.com/foundry/better_rails_apis_with_rabl
- http://teohm.github.com/blog/2011/05/31/using-rabl-in-rails-json-web-api
Let me know if there's any other useful resources not listed here.
Related Libraries
There are other libraries that can either complement or extend the functionality of RABL:
- versioncake - Excellent library for easily versioning your RABL APIs
- gon - Exposes your Rails variables in JS with RABL support integrated.
- rabl-rails - Reimplementation for RABL and Rails focused on speed.
Let me know if there's any other related libraries not listed here.
Troubleshooting
Examples
See the examples directory.
Issues
Check out the Issues tab for a full list:
- Rigorous benchmarking and performance optimizations
Authors and Contributors
Active Maintainers:
Thanks to Miso for allowing me to create this for our applications and release this project!
- Nathan Esquenazi - Creator of the project
- Arthur Chiu - Core Maintainer, Riot Testing Guru
- Tim Lee - RABL was a great name chosen by the Miso CTO.
- Douwe Maan - Multi support for caching, fixed test suite
- Andrew Latimer - Multi support for caching
- David Sommers - Template resolution, caching support, and much more
- Rick Thomas - Added options for extends and Sinatra testing
- Benjamin Yu - Added msgpack format support
- Chris Kimpton - Helping with documentation and wiki
- Marjun - Added xml option configurations
- Anton Orel - Added Rails 3.1 compatibility
- Sasha Koss - Added multi_json support
- Matthew Schulkind - Cleanup of configuration and tests
- Luke van der Hoeven - Support non-ORM objects in templates
- Andrey Voronkov - Added BSON format support
- Alli Witheford - Added Plist format support
- Ryan Bigg - Improved template resolution code
- Ivan Vanderbyl - Added general purpose renderer
- Cyril Mougel - Added cache_engine pluggable support and renderer tweaks
- Teng Siong Ong - Improved renderer interface
- Brad Dunbar - Pass current object into blocks
and many more contributors listed in the CHANGELOG.
Want to contribute support for another format? Check out the patches for msgpack support, plist support and BSON support for reference.
Please fork and contribute, any help in making this project better is appreciated!
This project is a member of the OSS Manifesto.
Inspirations
There are a few excellent libraries that helped inspire RABL and they are listed below:
Thanks again for all of these great projects.
Copyright
Copyright © 2011-2013 Nathan Esquenazi. See MIT-LICENSE for details.
Top Related Projects
Jbuilder: generate JSON objects with a Builder-style DSL
A fast JSON:API serializer for Ruby (fork of Netflix/fast_jsonapi)
No Longer Maintained - A lightning fast JSON:API serializer for Ruby Objects.
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual Copilot