I'll try to take a look at the rest of the guide tomorrow night (I have
a party tonight and I'm working right now). If the rest of the guide
doesn't require REST understanding then I'll prepare a patch and send as
a pull request (instead of pushing to railsdocs as I'm not sure if it
will be accepted and don't want to mess around). Otherwise I'll let you
know to understand what is your opinion on what we should do to the rest
of the examples in that guide...
Cheers,
Rodrigo.
Em 26-12-2012 16:53, Xavier Noria escreveu:
Hi Rodrigo,
I agree that section is too premature, someone new to Rails can get
started without such an introduction to REST. I definitely would use
the resources macro and do things in an idiomatic way, with idiomatic
routes and actions, but you do not need to introduce the whole
conceptual basis for that.
Would you like to work on a patch?
On Wed, Dec 26, 2012 at 7:24 PM, Rodrigo Rosenfeld Rosas
<[email protected]> wrote:
I've just enjoyed reading David's article named "The Parley Letter"
http://david.heinemeierhansson.com/2012/the-parley-letter.html
Except for the RSpec part, I generally agree with his opinions on that
article and found it a reasonable one.
I just stopped the flow of the read for a moment when I read this snippet:
" When I introduced REST as a concept for Rails in 2006, it wasn't because
of the intellectual purity of the prophet Fielding. It was because the
pattern provided real, practical advances for the code it was applied to.
Unweilding controllers gained a perfect straight jacket in the softest silk
to keep them under control. It made the connection between CRUD and the web
in such a way that we could just take the convention for granted and start
worrying about other things.
So I felt there was a lot there there. Granted, lots of others didn't at the
time, but today I don't see a lot of people arguing against the progress we
gained from that..."
In fact, I was one of those who didn't buy the REST argument. And I still
don't. And I haven't seen any progress gained by it either. Lots of people
seem to agree with me since I didn't see other Rails-like frameworks out
there becoming RESTful by default even many years later after Rails has
introduced the idea on Rails 2.
Maybe I could use it if I ever worked in some application that had the
requirements of being externally accessible through some public HTTP API.
But I've since then worked in something about 7 big apps since I started
working with Rails in 2007 (not all of them were Rails ones though, but some
were Grails ones instead). All of them are still actively
developed/maintained (although not by me, who am responsible currently only
for a single app since I joined my last company which has this single app).
I never had a need to support public HTTP based APIs in any of those apps.
I've also met other real apps since 2007 and talked to many devs and the
apps they maintained and even helped them sometimes and I couldn't find a
single app that would benefit from a REST API...
You might ask: "why do you matter?! It is not a big deal. Just don't use
it!". And I'd agree since it never bothered me that a scaffold generator
will generate RESTful controllers/views since I never used scaffold
generated code (except when learning Rails for the first time) even on Rails
1 era. And when I use the "controller" generator it generates the controller
and the views the way I want them to be generated. And even if I wanted to
generate a non restful scaffold I could write/use different templates. Then
why am I writing all of this?
Because I don't think a "Getting Started" guide should even mention REST:
http://guides.rubyonrails.org/getting_started.html
Nevertheless it is exactly in the second chapter (2.3)...
I don't think evangelizing REST makes sense if you read the rest
(interesting word, huh?!) of the article. Or even if you remember the first
articles/talks by David that I used to read by 2007 where people often
talked about developing a framework for 80% of the applications that are
usually built out there. How many of the apps out there need a REST API? I'd
guess less than 10%. Then why preaching about REST in the Getting Started
section of the Rails guides? I think that guide should be focusing on what
is common for 80% of the apps being developed, not by 10% of them...
It seems David has now changed his mind as he no longer talks about 80-20%,
but:
"So yes, the closer your application is to an application like Basecamp --
and I make that net extremely wide, I consider, say, 500px, Github, Shopify,
and others to fall into "close enough" -- the closer you are to the primary
use case that guides the development of Rails."
While the 80-20% idea makes sense to me, I don't think a popular framework
should be optimized for uncommon applications, like GitHub, Shopify or
Basecamp.
In summary, I'd just like you to consider removing the REST section from the
Getting Started guide or moving it far to the end of that guide.
Cheers,
Rodrigo.
--
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
--
You received this message because you are subscribed to the Google Groups "Ruby on
Rails: Core" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
