While doing some research on Rails and REST, I took stock on two things.
- It is relatively hard to find a clean, basic and printed explanation of how REST works with Rails. I found thousands of screencasts, and this single great guide.
- People do confuse CRUD with REST.
Especially the latter kept annoying me. While coaching a team I found out that clearly separating CRUD and REST helps people understanding what RESTful really means: Nothing more than HTTP restrictions.
I felt like sharing this insights with you.
Tell me, what is CRUD?
Every application has exactly one purpose: Maintaining business objects. This basically means: You got models that need to be created, displayed, updated and deleted using forms, lists and other fancy web UI elements.
If your Rails app would be managing beers, you’d write a
BeersController with actions like show, update, create and so on. The actions would mostly display forms and save attributes to models.
In order to access these forms in the browser you’d create routes, like
and map them to the respective controller actions I already mentioned.
This is what we call a CRUD interface: An application with descriptive routes, forms and usually pretty boring code – having one destiny: To Create, to Retrieve, to Update and to Delete.
Hey, this is CRUD!
Now, what’s REST?
Couple of years ago a new standard emerged, it is called REST and has the following main principles:
- The central concept of REST is the resource, which is a datastructure representing one or more business objects.
REST also encourages clean, simple, yeah, “RESTful” URLs – like
- They use HTTP verbs (GET/PUT/POST/DELETE) to encode what to do in the request, not in the URL.
- Something called content negotiation: We could request the resource in HTML representation, in XML, and more.
That’s what REST recommends, it does not say a word how to do it, just that we should.
What’s the difference?
I was wondering what differentiates REST from CRUD. Strictly speaking, both concepts ask the same two questions:
- Which resource are you interested in?
- What you wanna do with the resource?
Are there more similarities?
- The resource is the business model in CRUD.
- The CRUD route itself contains the verb (like edit or show) whereas REST encodes this information in the HTTP request type.
Again, the real difference is: Our CRUD code already implements this behaviour, whereas REST only recommends a standard for URLs (which I do appreciate!).
REST on Rails
Now, what Rails’ REST code does is nothing more than providing some “RESTful” helpers.
The real logic, the CRUD code, is still up to you (unless you’re using José’s InheritedResources).
How does Rails help me with REST?
It ships with a routing helper
resourcesthat creates numerous named RESTful routes for you.
- Some helpers as
form_forautomagically link to RESTful URLs for you depending on the model’s/resource’s internal state.
The essential thing about REST
The really cool thing about REST – beside nice, standardized URLs – is: you get a public API for free!
- query your models by GETting
/beers/1.xml, which usually returns a nicely formatted XML representation of your model if your code provides it.
- write to your database by POSTing to
/beerswhere they simply add POST parameters to fill in attributes in the new resource.
And so on.
They don’t need wiring code or a special binding library, they can just use HTTP to fuck up your database. Isn’t that great?
What’s your problem now, Nick?
Ok, summing things up, our logic is still CRUD, it’s not RESTful.
When speaking about short URLs and about different request types we should refer to REST. The rest… is CRUD (haha, a word-play!). REST is just a thin layer above our CRUD implementation, telling us how to format requests and URLs.
People will never understand the exceptional – the cool thing – about REST if we keep confusing CRUD and REST.