Q: Where do I put the code for creating the Period? Should I setup a
PeriodController and redirect from CalendarController to
PeriodController.create somehow? Or maybe I should just do Period.save
from CalendarController?
This seems to be a point of confusion. A “resource” in the Rails
interpretation of the REST convention is not a one-to-one correspondence
to “model” objects in an MVC design pattern. It just happens that models
tend to be represented by, and as, a resource.
However, you can certainly have resources that are not models and models
that are not resources. Think a a resource as anything that can be
described by the basic CRUD operations. In other words, anything that
can be manipulated by creating, reading, updating or deleting.
For example, user sessions are not necessarily represented by a database
table, so are not generally ActiveRecord subclasses. Yet you can
manipulate them as “resources” using the REST convention. The act of a
user signing into an application can be represented by “creating” a new
user session resource. And, the act of signing out then becomes a
“delete” operation on that resource. Notice that the other two CRUD
operations are not really necessary in this case The controller does not
have to be involved in the reading or updating of session objects. In
this case the object is directly manipulated since the manipulation does
not require an independent request-response cycle. So in Rails the
controller is not really required here.
The original concept of “web resources” defined by the HTTP protocol
(independent of anything Rails) were defined by pages and other files
stored remotely and accessed though HTTP. POST was intended for pushing
new pages/files to the server, PUT was intended to replace existing
pages/files with an updated/edited version, GET was to be used to access
existing pages/files, and DELETE obviously was used to destroy a
specific page/file.
Then the web browser was invented, by individuals that didn’t seem to
understand HTTP, and this whole concept was lost. RESTful conventions
are an attempt to return to the original intent of the HTTP protocol,
but in the context of the modern dynamic web. REST is intended to be a
bridge between HTTP CRUD (POST, GET, UPDATE, DELETE) and database CRUD
(INSERT, SELECT, UPDATE, DELETE). REST is also an attempt to bridge the
representation of the resources by using existing and well understood
formats (XML, JSON, YAML, HTML, RSS, ATOM, etc.)
Hopefully, this will help make it clear that REST is not a hard-and-fast
set of rules. It is a convention, and a framework, for standardizing the
server-client communication over the HTTP protocol. The important thing
is for you to “discover” what makes sense for your application and how
that best fits into this RESTful framework. And that is not always going
to be: “This is an ActiveRecord so it will always be a resource and have
it’s own controller.” Or: “This is not an ActiveRecord so isn’t going to
be a resource with it’s own controller.”
Well that was a long winded way to say: “It’s your application, do what
makes sense for your particular use case.” Keep the REST design in mind
if you think it makes sense and fits your case. That being said a lot of
people are finding that the REST approach really does fit a lot, dare I
say, most of the use cases people encounter. You just need to get your
head wrapped around it.