Skip to content


Robert Anniés edited this page Jan 11, 2016 · 17 revisions

Wiki Pages

REST Web Services with Rails & Toast

Implementing REST services in Ruby on Rails usually means to follow the steps:

  1. Create a set of models which should be exposed resourcefully
  2. For all models write a controller, maybe with help of REST plugins or RESTful routes, then craft by hand:
    • business logic, access control, paging into the controllers actions
    • remove and add actions according to the business logic
    • create the usual HTTP responses for the actions
  3. set up routing for the controllers

One ends up with a lot of controllers that are similar, but not quite the same. They all mix the REST logic - which is a technical aspect - with business logic. To my experience controller code, which is quite neat at the start, gets overwhelmed by business logic and becomes hard to maintain, because it appears to be easy and quick to do that, instead of refactoring some model code.

Toast is an experiment to separate the technical aspects of the controller (receive a request, decode it, do something with a model, create a response) from the business logic to that extent that coding a specialized controller becomes unnecessary. A widely recommended strategy is to code skinny controllers. For REST they become so skinny and similar that it makes sense to use a generic controller. Whatever there is different can be configured in the model class that is to be served by it. In other words: The model defines it's own controller.

So where is MVC then? I think in modern web apps the VC part resides anyway in the client, leaving the back-end alone with the models and the business logic. In many JS frameworks even the models appear in the clients as Javascript objects as proxies using REST. What we actually need are models on the back-end side that speak REST.

[Robert, 2012-08-22]

Advancing Toast

While the above outlined idea was successfully applied in toast up to v0.9 to productive applications some aspects of the configuration and implementation can be improved for better maintainability. Especially adaptations of requests using URL parameters are involved and hard to debug. Also model classes become bloated by the configurations and overloading associations.

The API configuration resides in a separate directory as Ruby files for each exposed model.

Toast v1 aims to simplify and separate the API configuration from the models, but it will remain a configuration. Only extensions to associations must still be programmed for processing URL parameters and implementing specific business logic.

As an important extension in Toast v1 an authorization policy DSL will be integrated.

More on the new configuration style can be read in the New User Manual, which I am currently outlining.

Toast v1 will be made for Rails 5 only.

[Robert, 2016-01-11]

Something went wrong with that request. Please try again.