A former boss used to refer to anything he put off as “Tomorrow Man’s problem!”

In the past decade of primarily developing as a “team of one,” I have been motivated to follow “best practices” largely by my knowing how pissed Tomorrow Man is going to be when he shows up for work and sees what I’ve done to his code!

Tomorrow Man loves it when I use source control, reproducible builds, and a bunch of other things on Joel Spolsky’s List, too :-)

I’d like to pick on one point though. You make a fairly solid statement that using RESTful routes is the only way to architect a Rails application. The problem with that statement is that is not always the case.

It’s true that REST is a useful paradigm, but that doesn’t mean that it is always the way to solve a problem. There are some web sites or applications that would benefit from a non-RESTful architecture.

Don’t forget that there is no single silver bullet that will solve every programming problem, there’s no single web application architecture that will apply everywhere.

As long as Rails supports non-RESTful methods, there will be a place for using them in Rails applications.

In examples urls above (e.g. “/photos” and “/photos/somephotoid”) “/photos” is the existing resource (the collection of all photos) a POST request asks to create a new subordinate (in this case, a new photo).

PUT handles entirely new entities or, if the Request-URI represents an existing resource “the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server”.

In this case PUT to the collection would, I’m assuming, mean either create “/photos” as an acceptable new resource if it did not exist, or alter the resource represented at “/photos” in some way.