This is Part 2, following Why CRUD? – Part 1
I realised some time later that I was not working on the site; the same thing was happening that had happened with PHP! I wasn’t developing because it was a pain. The code was horrible. I had developed a code base that I didn’t want to work with it!
Something needed to change. I liked Ruby and I liked Rails – something needed to change…
The thing that changed was me re-realising that URL don’t mean “The address you put into the browser and hope you get something back” but rather it meant: Uniform RESOURCE Locator! A URL is a (fully qualified) way to point to a resource on the internet. I wrote about this in 2003 on my personal site and touted the glories of “Extensionless URLs” but had seemingly forgotten my own example. /images/mycity should give the requestor what they want based on the HTTP_ACCEPT headers sent to the server, so if they want a BMP more than a PNG more than a JPEG they should get it, in that order, if possible. /images/mycity is a resource, the extension simply specified the format that the resource was in.
And it’s still damn cool.
Reading about REST and RESTful URL helpers in Rails made the somewhat dimmed lightbulb bright up again. I got it; I understood. The address in the bar is simply an address to a resource and we should give the user what they want (within reason).
Further limiting the thinking to basic CRUD (Create, Read, Update, Destroy) operations means that instead of getting /view/agents/:id I’d have /agents/:id linking to the show method in the AgentsController. Not to parrot too much but DHH was right: These constraints are liberating. No guessing that to talk about an Agent I have to look into the ViewController. How is that intuitive? Why should I have to worry about that crap? Let a convention deal with it.
So I was all about Rails again, which was good because about the time my interest in Rails was really really growing (again!) I was hired to do Rails coding.
Part 3 will deal with having to use an existing non CRUD/RESTful codebase and then being able to write an API to use CRUD/REST exclusively.
