WHY Rest

rubyonrails-talk
41

The need for a separate search controller would most likely apply if you were CREATING new searches, as in a user wants to create and save a search for use later.

A search, at its simplist, should not be a create (post). A search is almost always a GET, as you are retrieving a resource. Put simply… searching can just call the index action, and the index action can just grab the search parameter.

/users/?q=hogan

def index

if params[:q].blank?

@users = User.find(:all)

else

@user = User.find_all_by_keyword(params[:q])

end

end

That would be keeping it simple. No need for a separate “search” action in the controller… leverage the way Rails does REST. A search is a retrieval, so it’s a GET. Creating a search action that accepts a get would work as well, but I like to keep it simple.

Plus, not using POST for searches greatly reduces some user stress, as they can hit the back button without the annoying “page expired” thing.

Just my way of thinking, others will disagree I’m sure.

42

@Anton:

AHA! You, my friend, are finding exactly what I found about 2 months ago. You are doing things correctly, no doubt, but here’s what I find to be the key to REST:

REST is for web services, really. However, the advantates come into play in terms of organization. Just like Rails organizes your code into models, views, and controllers. You don’t have to do that organization. You could just use ERB with no controllers if you wanted to, and do all your finders in the views. Would you? Probably not because it’s more organized.

One benefit the Rails framework has is that a developer can look at your project, then look at mine, and pretty much know where to start. Another selling point of Rails is “convention over configuration.”

The core team adopted REST and has provided a mechanism to organize code into this new convention. Once you adopt it, you write less code and are more productive. These conventions are not something you absolutely have to follow. There is a lot of hype around REST in Rails, just as there was a lot of hype about Rails in general.

You’ve asked some great questions and started a great discussion. I’ve provided my thoughts about how to architect something earlier, as have some others. You’re still asking for the “how” and the “why”. At this point, I’m not sure what you’re after. But I’ll take a guess as it was probably the part I was hung up on:

You say that not every app is CRUD. I completely disagree. After doing web apps for near 10 years, I can assure you that every app I ever worked on is creating records, reading them, updating them, or deleting them.

  • setting a student to be enrolled in a course? Creating an enrollment record

(/enrollments → :post, not /workshop/1/enroll_student/2)

  • Search for an aparment?

/apartments?city=chicago&bedrooms=4&lowprice=100000&highprice=300000

  • Log a user in

(/sessions => post), not /login/login

Adding custom methods to the REST routing is, in my opinion, there for two reasons:

  1. to allow people not familiar with REST to “cop out”, or more nicely put, get stuff done without overanalysing

  2. To provide methods that are ONLY needed on the web, like the NEW and EDIT view pages, or an advanced search form. You never need those from the webservice point of view, but you do need to show them to your web users.

Does that help at all?

43

It looks like you folks are jumping into implementation details, so I apologize for inserting this short philosophical discussion in the middle of it, but if I don't type it now, I probably never will.

I recently converted to REST after being a hater for a while, and I'm glad I did. I think that the REST vs. Non-REST debate is similar to writing valid vs. invalid (x)html, or even writing presentational vs. semantic markup. Don't get me wrong, I am NOT trying to offend anyone here, or say that someone who is not using REST architecture might as well be writing invalid, table-based html. Again, that is NOT what I mean. What I mean is that the pro and con arguments for each of those cases are fairly nebulous, and (insert controversy) when you take a long step back, in the grand scheme of things, I doubt it has any impact on the world whether my markup is valid xml or not. However, I do write semantic, valid xhtml, because I personally like it better, and think it's A Good Thing To Do. Others think it's too much of a pain, and choose not to. I do, because I like it.

Why do I like REST? I like it for two reasons. One, because it encourages me to compartmentalize my controller code into manageable chunks, whereas left to my own devices, I'd probably write huge sprawling messes. Two, because it forces me to spend more time thinking about my application, how it all fits together, and what the pieces really mean. That's it! Those are the only compelling reasons why I continue to use REST design principles! If those aren't issues for you, then don't use it.

There are three points that were key to my adoption of REST that I've not seen mentioned yet.

FIRST: REST goes beyond Rail's map.resources implementation of it. YES. Rest is bigger than Rails. Heck, if you really wanted to, you could write a large, fully restful service with one controller and some fancy routing. In fact, in some cases I have done that (which blows away point #1 mentioned above). I would suggest picking up a copy of O'Reilly's RESTful Web Services book. I found the book to be poorly written and inconsistent, *but* it was great to see REST outside a Rails context. And it will help you discover my next point:

SECOND: RESTful URL's do not necessarily have to be the ones generated by map.resources. Recently I created an application that would render graphs of the number of species discovered, per year, at any level of the taxonomic tree, for any given date range. One of my URL's, the one for getting the graph images themselves, looks like this:

This route renders a PNG graph of all species discovered in Kingdom Animalia between 1860 and 1923 http://host/graphs/kingdom:animalia/1860-1923.png

This route renders a SVG graph of all species in Family Hominidae (that's us!) between 1850 and 1960 (Neanderthal was discovered in 1856 I believe) http://host/graphs/family:hominidae/1850-1860.svg

These URLs are RESTful, are routed to my GraphsController#show with a custom route, and they're beautiful. One of the more useful sections of the O'Reilly book are their suggestions for creating URLs

THIRD: You need a REST buddy. REST is really hard to figure out by yourself when you don't fully get it. In fact, some times it's really hard to figure out even when you DO get it! Having a buddy to bounce ideas off will be extraordinarily helpful.

I hope this is helpful, -Ryan

44

Nice Post Peter,

The advantanges of REST are like a sort of synergy. We can right apps like we used to 10 years ago, or we can move on and use cool new ways. How long would you take to decide the naming of basic operations using non-REST ways? quite some time, specially if you are in a big team of developers and each one has their own take on how things should be done. REST, uses a convention that no one has to dispute, because it just makes sense. We are going to use what the HTTP protocol has had all along, but no one has used, the HTTP verbs PUT and DELETE. That simplification is beautiful, and it doesn't need any ramp up time, of reading documentation about your site, to figure out how it works.

Okay so simplicity because the naming of your basic operations (read, write, update and delete) and already decided for you, and everyone new to the project knows that, so you save time of explaining why you coded things one way or the other.

Another advantage, you have to think harder about your design to make it restful, you can't just be adding methods left to right like crazy. As soon as your controller goes over 20 methods, you have to stop and think. Think about a better way to structure/design you application. As you say Anton, not all applications are suited for this design, but most of them are, it's just that we haven't done it before and not sure how to tackle it. Maybe this helps, think about the objects of you application, any object/noun can have its own controller-model-view, which in most cases will lead to more controllers but very simple controllers that you can understand in no time. So, instead of facing a 100 method controller you have 10 controllers with 10 methods, and 7 of them are the same in all controllers. Isn't that beatiful and easy to understand?

Okay another advantage. Once you have 10 controllers instead of 1 huge one, you can test it much better. Let me refrase that, spec it :slight_smile: cause we like BDD, don't we? So, you can write simple specs to make sure each of those controllers does its job right, and that they all comunicate with each other correctly, using for example, the all might rspec Stories, which are freaking awesome :slight_smile: So, your application will become easier to spec and thus to maintain and extend with confidence.

Another advantage. Information and continuous improvement of the site. In my opinion an app, is never complete, it can always be enhanced with new features, re-factored, made more robust and become more useful by deleting features that are of no important use. Thus, if we all use REST we will be able to share information with other sites and enhance our own site with more information. This information needs to be readily available and easy to access and update. REST lays down the guidelines for everyone to have a common language. If I know you have a site about car rentals with all the rates in xml form at the url yousite.com I don't need to know anything else to access your data and add it to my site. I already now yousite.com will give me all your rates in xml form, and adding them to my database is trivial. In addition, we can join forces just as easily, and I can add rates to your site by going to yousite.com and filling out an html form or simply sending you some xml data. This is very powerful, and I only need to know the noun you used to represent your information.

As you can hopefully see, there is no one advantage about REST, its more of a synergy of small things that make the development of REST applications a happy and beautiful process, we like happy and beautiful right? we don't want frustration and reading long, cryptic code/documentation, we want simplicity, get it done, and move on, don't worry be happy dude :slight_smile: Rails has brought happiness to my life, and REST has brought even more happiness to me and my co-workers, thing about them too :slight_smile:

Hope that helps

Raimond Garcia

45

A search, at its simplist, should not be a create (post). A search is almost always a GET, as you are retrieving a resource. Put simply... searching can just call the index action, and the index action can just grab the search parameter.

......

Just my way of thinking, others will disagree I'm sure.

I agree with you 100%, Brian. The only time I've wanted to elevate search to a separate controller is when it is doing multi-model searches, and even then it was still a GET.

46

Ryan Bigg wrote:

Is it enough to not type something as horrible as:

link_to @topic.name, { :controller => "topics", :action => "view", :id => @> topic.id }

when Restful Routing gives you: link_to @topic.name, topic_path(@topic)

I'm just starting rails, second week now, been into python and zope for 6 years. I actually find rails cool, but things like

topic_path(@topic)

takes me forever to FIND THIS convention. I need INSANE amounts of time to find how everything is phrased, instead of just writing an extra line of code.

Sorry for being off topic a bit here.

A

47

Just do 'rake routes' and its all there.

48

This is one commonly-touted benefit that isn't quite accurate. In addition to knowing the URL, you need to know the structure and semantics of the XML data. So while using it is obviously simpler than if it were a WS-* service, it's certainly not free.

That's one of the promises of microformats. Of course, they haven't quite taken off yet.

Pat

49

Well, technically you don't if it's a Rails REST resource and you use ActiveResource. You could reflect on it like ARec, but I get your meaning. :slight_smile:

--Jeremy

50

Very good point. On the other hand, in many cases the structure and semantics can be obtained by inspection.

///ark

51

Does anyone know of a book or a sample non-trivial application that is solely based on creating RESTFul applications? I have RESTFul Web Services Orielly book which has a broad based discussion. I would prefer a more focused RailsSpace like book. The keyword is "non- trivial". Thanks. Bharat

52

Bharat said the following on 05/01/08 04:07 PM:

Does anyone know of a book or a sample non-trivial application that is solely based on creating RESTFul applications? I have RESTFul Web Services Orielly book which has a broad based discussion. I would prefer a more focused RailsSpace like book. The keyword is "non- trivial".

I found this, which seems to meet the 'non trivial' requirement. It interested me because it was a refactoring and redesign, which is what I've been trying to unearth in this thread. It seems to be a 'proof by example' rather than a 'proof by assertion'

http://scottraymond.net/2006/7/20/refactoring-to-rest/

It is just another 'talking point'? http://www.sourcewatch.org/index.php?title=Talking_points

He gives numbers and lists of the 'before and after' and says "The process was gradual.."

Maybe we can all ask him for more details.

53

Brian Hogan said the following on 05/01/08 10:49 AM:

One benefit the Rails framework has is that a developer can look at your project, then look at mine, and pretty much know where to start. Another selling point of Rails is "convention over configuration."

I don't think that's a fair analogy, Brian. I can read Latin, French, Spanish and a couple of other languages at the 'find my way around the airport and order a meal' level. But I can't write or peak them.

I wrote compilers early in my career, and interpreters and DSLs. I know how computer languages work. I've earned a living writing in about 12 different ones including SmallTalk and FORTH, but I find RPN hurts my social life (too much RPN during the day and it spills over into the night). So _reading_ a language isn't a big deal. Figuring out other people's code ...well that depends. I've done maintenance on some awful code in my time, again for a living. It instilled me with "I don't want anyone to think about me what I'm thinking about the guy who wrote that code".

Rails is nice; the 'convention over configuration' means things are in the right place when you come to look for them. It makes it much easier to understand than some 'ad hoc' application. Compare Instiki with Socks, both wikis written in Ruby, one in Rails, the other 'ad hoc'.

But you've tried to extend this to something else. I can read an application written in RESTful Rails and understand it, but like reading and understanding Latin or French, that doesn't mean I could compose one.

As for every application being CRUD, well I can see that if you're stuck with Rails and the Web and a database backed system you're going to get channelled that way. But people are using the Active* without database.

I can also imagine things like games where the CRUD might be used to, for example, load the maps/terrains and flight characteristics for a flight simulator, but the actual 'flying' isn't CRUD.

54

voodoorai2000 said the following on 05/01/08 11:59 AM:

Another advantage, you have to think harder about your design to make it restful, you can't just be adding methods left to right like crazy. As soon as your controller goes over 20 methods, you have to stop and think. Think about a better way to structure/design you application. As you say Anton, not all applications are suited for this design, but most of them are,

I seem to have an uncanny knack of picking the maverick ones then! When I think back, the only completely CRUD system I ever did was an accounting package in DB 4GL called Progress.

I'm old enough and scared enough that I wok out alternatives before implementing. I've been known to run many test examples to find out hwo compilers 'work'.

Perhaps that's why I'm comfortable with 'constrained' approaches (you call it 'convention over configuration' but its had other names in history) rather than an 'infinitely rich colour pallet' for my artists brush. If you'll pardon the analogy. I've found hat constraints means focus.

So I get a lot of "yes, so what?" to that's being said about structuring for REST. The slicing and dicing of command and control and responsibility isn't new; I was taught it over 30 years ago.

it's just that we haven't done it before and not sure how to tackle it.

LOL!

Maybe this helps, think about the objects of you application, any object/noun can have its own controller-model-view, which in most cases will lead to more controllers but very simple controllers that you can understand in no time.

You grew up speaking English, I guess. Not all languages work that way and some languages you have to match up the cases, declinations and conjurations as well as temporallities. There there's languages like Navaho which are so radically different you can't really comapre them with the Indo-European ones.

English, the subject - verb - object, way is either terribly sloppy or terribly tollerant depending on how you look at it. Native speakers can gloss and use idioms that are unintelligble to ESL, and non native speakers can produce terribly fractured English with cases and tenses all wrong but still be understood. Few other languages are that 'tollerant'.

My point here is that even with the CMV, 'there's more than one way to do things'. I can make my controllers skinny in number of ways; by offloading code into the models, into the views, into the helpers or into libraries. I can build a controller around no methods except 'method_missing'. I can build it with lots of exception handlers and few "if" statements that do checking (http://blog.codefront.net/2007/12/10/declarative-exception-handling-in-your-controllers-rails-20-a-feature-a-day-2/ http://railsforum.com/viewtopic.php?pid=49600 http://nullstyle.com/exceptional/ and others)

So, instead of facing a 100 method controller you have 10 controllers with 10 methods, and 7 of them are the same in all controllers. Isn't that beatiful and easy to understand?

You remind me of the English language teachers or possibly the "Business Communication" who advocate short sentences with strong verbs and concrete nouns. They are asking you to ruin the language. Here's a pointer to a parody of one of the great works of our language with that applied: The Gettysburg Powerpoint Presentation

John Kenneth Galbraith is one of the most clear, fluent writers of technical and business English. In one of his books I encountered a sentence that ran on for one and a half pages. I did a double take when I realised it and went back and wrote the sentence out by hand, decomposed it, and tried reformulating it a a number of shorter sentences, with, alas, no success in preserving the clarity and impact the original, and I do not believe that was due to any shortcoming in my ability to handle the language. It was beautiful. It was graceful. It was easy to understnad. But short it was not! (Now re-read this last paragraph.)

One "traditional" way of judging code quality comes from the days of "goto-ful" programming. With "GOTO" you needed to remember where you came from as you flipped back and forth though the lsitings. So if you needed more than a places where you had your finger stuck in the fanfold as a placemaker it was called a 'more than five finger program'. On can make the case that a single file is easier to scan that having ten different controllers and having to grep to find which one has the method, its all in one and your pinky finger just has to hit the '/'.

YMMV.

Okay another advantage. Once you have 10 controllers instead of 1 huge one, you can test it much better. Let me refrase that, spec it :slight_smile: cause we like BDD, don't we? So, you can write simple specs to make sure each of those controllers does its job right, and that they all comunicate with each other correctly, using for example, the all might rspec Stories, which are freaking awesome :slight_smile: So, your application will become easier to spec and thus to maintain and extend with confidence.

You're arguing in a circle.

Another advantage. Information and continuous improvement of the site. In my opinion an app, is never complete, it can always be enhanced with new features, re-factored, made more robust and become more useful by deleting features that are of no important use.

And eventually become obsolecent ...

Thus, if we all use REST we will be able to share information with other sites and enhance our own site with more information. This information needs to be readily available and easy to access and update.

That's a non sequitor. It may or may not be true; it may or may not be an advantage, but it certainly doens't follow on from the previous sentence.

One can, for example, add a RSS feed, or an RSS input, to a site with little difficulty, without needing REST. One might even think of RSS as 'just another "skin"' defined by different template.

REST lays down the guidelines for everyone to have a common language. If I know you have a site about car rentals with all the rates in xml form at the url yousite.com I don't need to know anything else to access your data and add it to my site.

I'm sorry: are you saying you need REST to output (or input) XML? I don't think that's the case.

As you can hopefully see, there is no one advantage about REST, its more of a synergy of small things that make the development of REST applications a happy and beautiful process, we like happy and beautiful right?

Actually no.    "The reasonable man adapts himself to the world; the unreasonable one     persists to adapt the world to himself. Therefore all progress     depends on the unreasonable man."     --George Bernard Shaw

Discontent presents a challenge.

Hope that helps

       ____ ___ ____ _ _ __/\__/ ___|_ _/ ___| | | |_/\__ \ /\___ \| | | _| |_| \ / /_ _\ ___) | | |_| | _ /_ _\   \/ |____/___\____|_| |_| \/

55

Wow. You guys definitely take these discussions pretty seriously. Each person counter-arguing back and forth on every point the previous person made. That is impressive how much the community cares about getting to the bottom of "Why REST". Interesting to see so many opinions on both sides as well as the truthful "I just don't understand yet..." posts.

I am curious to hear from people more in detail about something:

If you consider RESTful Rails approach to be useful, have you always been convinced? If so, why did you jump on the wagon so quickly? If not, what was the primary thing that contributed to you eventually being convinced of the merits of REST.

If you consider the RESTful Rails approach to be not so useful and do not plan on using it yourself in the future... have you ever tried the RESTful approach? If not, what stops you from at least giving it a chance for one application before making judgement? If you have tried it and never intend to use it much again, what were the reasons that you found it to be lacking. Any suggestions on how to improve it in the future?

As for my personal take, I have been doing non-REST Rails for a long time and I was frankly skeptical that it would be worth my time to learn. I wasn't planning on using it, I had watched the tutorials, read the posts and it just wasn't convincing. Then, I started work on a project with a team member who was sold on REST and we developed in a RESTful way for Rails 2.0 and now I am a believer as well. I won't go on rambling much longer but I concur with a lot of what the RESTers are saying and I really enjoy sticking with the "convention" which in Rails 2 is fairly obvious.

56

I gave REST a serious try with my last few projects because what I was doing in Rails just didn’t feel right. I felt that I was typing too much, being too verbose and in some cases not DRY, but not knowing why or what to fix.

With REST, I now enjoy Rails development quite a bit more for the following reasons:

  • Consistency across all controllers. I feel like I’m building a Rails site instead of a bunch of web pages handled by Rails.

  • Much less typing: resources_url instead of :controller => “resource”, :action => “index”

  • Following from the above, code is much cleaner and easier to read / maintain.

  • Occasional plus: RESTful webservices are almost free, just add XML output to the actions you want exposed.

  • Helps me develop smaller controllers, more controllers, and fatter models, leading to better encapsulation and easier / better testing.

Of course, with Rails you can still drop back to the old way if you have a controller that just doesn’t fit the REST mold, there’s nothing wrong with that.

As Nathan says, you really can’t convince someone by pointing them to reading material. You can know the ideas, know how to do it in code, but until you actually do it once or twice will you know why REST is just a good way to go, and this is not Rails specific but for any website you happen to create.

Jason

57

@Anton

Disagree all you like, but all Rails apps have the same structure, and unless you’ve violated how Rails works, yes sir, I can pretty much tell what you were doing. Again, that’s if you followed the conventions instead of hacking up your own way of doing things. That’s a far cry better than “Bob’s PHP framework created by company XYZ”. Frameworks, in general, make apps more maintainable. The more conventions the framework has, the more maintainable the code is. Taking things to the next level of convention with REST results in lower amounts of code, which is less to maintain.

I can also imagine things like games where the CRUD might be used to, for example, load the maps/terrains and flight characteristics for a

flight simulator, but the actual ‘flying’ isn’t CRUD.

The flying in a flight sim is CRUD. You are Reading and Updating some resources. No matter what you do in application development, you can think if it in CRUD, and that’s what REST in Rails asks you to do. Anything you can come up with can be modeled that way. Just because it doesn’t appear that way to you doesn’t make it false.

If I change a method on an object, that’s technically an UPDATE.

plane.increase_speed (update)

plane.current_speed (read)

plane.altitued (read)

plane.increase_altitude (update)

You can argue against if you want, but that’s the way people who have embraced REST think of it.

58

Brian Hogan said the following on 06/01/08 12:38 AM:

The flying in a flight sim is CRUD. You are Reading and Updating some resources. No matter what you do in application development, you can think if it in CRUD, and that's what REST in Rails asks you to do. Anything you can come up with can be modeled that way. Just because it doesn't appear that way to you doesn't make it false.

If I change a method on an object, that's technically an UPDATE.

plane.increase_speed (update) plane.current_speed (read) plane.altitued (read) plane.increase_altitude (update)

You can argue against if you want, but that's the way people who have embraced REST think of it.

THANK YOU ! ! ! !

At last, something tangible instead of the same old hoary oft-quoted examples.

THANK YOU ! ! ! !

(Only 4 exclamation marks. I take not of what pTerry said.)

Now I just need a brainstorm to see how that maps to what I'm doing. What I'm faced with is that apart from the web services of 'list' there's not a lot of public-facing functions for the parts of a wiki. Even the models themselves aren't actually public facing since the sole 'resource' is the wiki itself.

Another way of looking at this: an admin interface might let you get at the individual tables and bypass referential integrity - or patch it up for maintenance purposes. But you don't want a publicly exposed URL that can be hacked. (If you want I'll start a branching thread about security trivia.)

In this example, the GUI may have buttons for the planes controls, but there are other 'resources', internals like fuel and internal state ("Houston, we have a main bus A undervolt now, too... It's reading 25 and a half. Main bus B is reading zip right now... We got a wicked shimmy up here.") Well not quite. But fuel consumption and how it affects COG are flight characteristics are internal functions not something that's exposed as a URL.

This is is one of the conceptual issues I'm facing.

Or let me put it another way. There is a flying technique where you don't touch the throttle. The user interface is the joystick. joystick.forward is an exposed function. The ensuing plane.tilt causes a time dependent plane.increase_speed and plane.decrease_altitude and plane.have_wings_ripped_off_at_roots and plane.crash_onto_ground, but those are not exposed by any URL. Or at least in a good design they are not, since the interface is only there to model the available controls. Note also that some of those functions are timed and not a response to the user clicking a button.

Now my analogy only goes so far because while plane engines (or at least the 'small' prop-driven ones I'm familiar with) do have engines which run at 'constant revs' (unlike auto engines), they also have throttles (how else would you start them up?).

But I'm sure we can come up with a 'resource' that not only must not have any functionality exposed, but one whose operational integrity can be subverted by using a URL with suitable parameters.

Lets face it, that

        map.connect ':controller/:action/:id'

or its equivalent is a security risk. (If you don't see why then good for you; you're one of the 'good but naive' guys.)

59

Now I just need a brainstorm to see how that maps to what I’m doing. What I’m faced with is that apart from the web services of ‘list’

there’s not a lot of public-facing functions for the parts of a wiki. Even the models themselves aren’t actually public facing since the sole ‘resource’ is the wiki itself.

Don’t think of REST as public facing resources.

Maybe I want to modiffy the wiki using a nice GUI client or an OSX widget instead of a web interface. You expose all the CRUD features of your wiki via REST, wrap them with http basic authentication, and then you have an api other devs can extend to provide nice features to your wiki.

Imagine a product page on your wiki. When you tag a new release in SVN, the changelog gets posted to the appropriate spot on the wiki.

Imagine an integrated ticketing system that could send FAQs up to your wiki based on helpdesk calls.

Web services / REST isn’t just for the public. It’s for you!

As for REST and a flight sim, it’s not something I’d do on the web with a stateless bit of code. That’s really something you want a client-side thing to do so you can maintain states, use events, etc. You probably could do it with Rails, but I wouldn’t. I dont’t think that’s the right tool for the job.

60

You grew up speaking English, I guess. Not all languages work that way and some languages you have to match up the cases, declinations and conjurations as well as temporallities. There there's languages like Navaho which are so radically different you can't really comapre them with the Indo-European ones.

Navaho.... that's funny :slight_smile:

English, the subject - verb - object, way is either terribly sloppy or terribly tollerant depending on how you look at it. Native speakers can gloss and use idioms that are unintelligble to ESL, and non native speakers can produce terribly fractured English with cases and tenses all wrong but still be understood. Few other languages are that 'tollerant'.

My point here is that even with the CMV, 'there's more than one way to do things'. I can make my controllers skinny in number of ways; by offloading code into the models, into the views, into the helpers or into libraries. I can build a controller around no methods except 'method_missing'. I can build it with lots of exception handlers and few "if" statements that do checking (http://blog.codefront.net/2007/12/10/declarative-exception-handling-i...http://railsforum.com/viewtopic.php?pid=49600http://nullstyle.com/exceptional/ and others)

The point is putting things where they belong... Of course you can put them where ever you want, but then other programmers are going to have to chaise your code around.

> So, instead of facing a 100 method controller you have 10 > controllers with 10 methods, and 7 of them are the same in all > controllers. Isn't that beatiful and easy to understand?

You remind me of the English language teachers or possibly the "Business Communication" who advocate short sentences with strong verbs and concrete nouns. They are asking you to ruin the language. Here's a pointer to a parody of one of the great works of our language with that applied:The Gettysburg Powerpoint Presentation

John Kenneth Galbraith is one of the most clear, fluent writers of technical and business English. In one of his books I encountered a sentence that ran on for one and a half pages. I did a double take when I realised it and went back and wrote the sentence out by hand, decomposed it, and tried reformulating it a a number of shorter sentences, with, alas, no success in preserving the clarity and impact the original, and I do not believe that was due to any shortcoming in my ability to handle the language. It was beautiful. It was graceful. It was easy to understnad. But short it was not! (Now re-read this last paragraph.)

That might be true for Literature. However, for programming, short precise methods and controllers lead to better designed and modular apps.

One "traditional" way of judging code quality comes from the days of "goto-ful" programming. With "GOTO" you needed to remember where you came from as you flipped back and forth though the lsitings. So if you needed more than a places where you had your finger stuck in the fanfold as a placemaker it was called a 'more than five finger program'. On can make the case that a single file is easier to scan that having ten different controllers and having to grep to find which one has the method, its all in one and your pinky finger just has to hit the '/'.

Well I guess its a matter of taste, but to tell you the truth, if I saw a 120 method controller, I would simply think the programmer is in a rush and didn't have time to think thoroughly about the design of the app, not that he prefers to search for a method name in just one file.... I know you where just trying to explain a possible argument, but... come on now :slight_smile:

YMMV.

> Okay another advantage. Once you have 10 controllers instead of 1 > huge one, you can test it much better. Let me refrase that, spec > it :slight_smile: cause we like BDD, don't we? So, you can write simple specs to > make sure each of those controllers does its job right, and that they > all comunicate with each other correctly, using for example, the all > might rspec Stories, which are freaking awesome :slight_smile: So, your > application will become easier to spec and thus to maintain and extend > with confidence.

You're arguing in a circle.

Not at all, this is regarding testing my friend, a crucial aspect of software, that many people underestimate and later suffer the consequences. By encapsulating the functionality of your app into smaller units, your testing becomes simpler.

> REST lays down the guidelines for everyone to have a common > language. If I know you have a site about car rentals with all the > rates in xml form at the urlhttp://yousite.com/ratesI don't need to > know anything else to access your data and add it to my site.

I'm sorry: are you saying you need REST to output (or input) XML? I don't think that's the case.

Nop, what I was saying is that REST combined with Rails gives you an XML interface, with very few lines of code. Of course you can play around with XML in many ways, but I doubt you can do it faster and so well structured, as having a respond_to block that takes either html or xml, and returns the output accordingly.

> As you can hopefully see, there is no one advantage about REST, its > more of a synergy of small things that make the development of REST > applications a happy and beautiful process, we like happy and > beautiful right?

Actually no. "The reasonable man adapts himself to the world; the unreasonable one persists to adapt the world to himself. Therefore all progress depends on the unreasonable man." --George Bernard Shaw

Discontent presents a challenge.

That is a good point, and exactly what DHH, the core team, and all the contributors, have been fighting for in the last 3-4 years. We have already changed the way software is developed, and will surely keep improving. Rails, REST and BDD are part of this software revolution. Once they become mature techniques, we'll jump onto the next big thing, which most of us, probably can not yet even imagine, but will surely come. In the meantime, they are the best tools and design arquitectures that we have.

P.S. For some obscure reason, Anton, you are making me an even stronger believer in the REST philosophy, thank you :slight_smile: