Ruby on Rails assumes you will be developing your controllers and views with a
RESTful architecture in mind. What this means is that if you have a
posts, a model named
Post and a controller named
PostsController you have some URLs automatically available to you.
In fact, creating the associated migration, model, controller and view is only
a couple of scaffold generation commands away. Once you have this all setup
though, you begin to ask yourself “What’s so great about this?” Besides
being easy to create all of these files and hook them up, what’s the actual
added benefit of structuring my code this way? This only becomes more apparent
when you start adding additional functionality, for example you want an
ArchivesController that lists your blog entries by date.
You realize that you don’t want all the fancy PUT, POST, DELETE actions, and
your URL structure is actually entirely different from the RESTful architecture.
Do you still have to keep using REST? Should you restructure your
ArchivesController to fit the RESTful architecture?
The short answer is no, you don’t need to use REST. REST is great for some projects and some entities, but not for others. Generally it’s also a good starting point, and more importantly it creates a basic protocol that you or other developers, in the case of an API, can depend on. It doesn’t require you to remember what you need to do to create a new entity, you simply make a POST request. That said it’s not the be-all-and-end-all of software architecture. For example, a web-site’s marketing pages (/about, /tour, /pricing, /special-offer-december) usually do not fit well into a RESTful architecture, and additional functionality like search (HTTP Get /posts/search) or stats (HTTP Get /posts/stats) is often added in parallel to the RESTful architecture.
Before you get started, here are some questions you might want to ask yourself:
As a guideline, if you answer YES to these two questions, then it’s probably best to start with REST and expect that you will eventually use the architecture as a building block for additional actions and views you might want to perform. Otherwise, pick a URL that best represents what the action will show or do (/archives, /tour, /december-offer) and make sure you use the proper HTTP Protocols (GET for display, PUT for update, DELETE for removing and POST for creating).