Why CRUD? - Part 3
In the last part of what is probably going to obnoxiously long I realised that not using CRUD was making the application codebase ugly and making me not want to work with it. I rediscovered resources and discovered REST.
One of the projects at my new job was to migrate two Rails SVN repos into one (combining both Rails projects). I must admit that the codebase wasn’t the best I had seen. It was clearly designed without REST in mind (especially considering there was no simply_restful and no rails 1.2) or CRUDdiness in mind. A lot of actions in controllers and a lot of scoping (addComment to some model in the model’s controller, for example).
Tracing through the code was difficult: views had partials referencing partials that referenced other partials. If the project was started from scratch right now (the client would probably freak out) and it would definiately have a better structure.
After I had merged the two SVN repos into one work began on adding more features and bugfixing to the same application. The usual “Getting to know the codebase” time was applicable, but I can’t help wonder what may have been if it had used REST concepts in the beginning adding to it and maintaining it would be much easier (but I may be biased).
Eventually I’ve become familiar with the codebase and understand how it works and its quirks. I’d love to talk the powers that be into letting us rewrite it RESTfully… but I doubt that will happen any time soon. 
Maybe Version 2.0.
The next project was one from scratch to expose an API to a database. In the beginning SOAP through ActionWebService was considered but ultimately discarded in favour of a RESTful design, much to my relief! ActionWebService::Struct derrived classes would have numbered in the hundreds in an effort to map the data combinations. Yick.
And so I got to design a RESTful design, this is where I really got to see the goodness of REST; prior to this project everything was just theory. Now I had to chose between scoping methods (PeopleController#addAvatar, which was actually creating an Avatar) or REST. I researched more into REST, played, and was thankful to see that it wasn’t as hard as I had imagined. Rather, it was easy. Very easy, almost too easy.
The project in question is a large scale and involves a dozen or so people. There is a Java part, a Flash part, a Rails part and those crazy art-type people (who I believe practice dark arts to make such images appear on paper and computer screens!). The Java and Flash guys had the harder part. All I had to do was architect a bunch of models and controllers to do CRUD operations with an agreeable data envelope (we chose JSON). Everyone else had to knit everything together and make it all work. CRUD is easy, Working with Java and Flash is painful.
Part four will talk about the way I went about architecting the API. It’s going to be very boring - CRUD is predictable (which is good!)
