I've done the research and written some trivial applications - so I've
got a basic understanding, though still just a bit beyond noob.
Anyhow, I'd like to begin writing my first "real" application and am
wondering whether or not to make it a RESTful app or a "traditional"
Rails app. Any thoughts from more experienced folks?
Do you plan on offering any XML-based services? If not, then it may not really be worth it…other than as a learning experiment. Depending on what your app does, it may be just as easy to make it RESTful as to not. Highly complex apps tend to be more difficult to shoe-horn into the REST methodologies (so I’ve found anyways).
ed
I say give it a try. There’s nothing in the routing mechanism to stop you from using RESTful and non-RESTful [tiresome?] methods. If nothing else, it’s a good exercise and learning opportunity like Ed said.
Just my two cents.
RSL
You have it very wrong. I'm not sure where you're getting the idea
that REST depends on or is even related to Javascript.
Pat
I think he might have been referring to Rails' implementation of REST
which AFAIK relies on javascript to set http methods on links for
methods other than :get.
-jc
Pat Maddox wrote:
It is true that a web browser that doesn't or won't support javascript
will not be able to use an interface that is reliant on REST. That
particular use of REST is just the tip of the iceberg; the more
interesting use cases are things happening behind the interface, where
javascript doesn't really matter.
g.
Correction: javascript is only used for setting the http delete method.
Jesse Clark wrote:
That's just a convenience, Rails will also treat POSTs with a _method
parameter of 'put' or 'delete' as PUT or DELETE requests. So,
javascript is used for simplicity, but you'd have to add a fallback
(GET /whatever/1/confirm?) with a regular HTML form to confirm the
deletion. This way when someone's web accelerator decides to prefetch
your links, it doesn't 'click' your delete links and clear your data.
http://www.37signals.com/svn/archives2/google_web_accelerator_hey_not_so_fast.php
http://www.faqs.org/faqs/www/cgi-faq/section-37.html
The links generated by passing :method => :delete to link_to uses javascript in the resulting link's onclick attribute to create a form containing a hidden field with name='_method' and value='delete' but the link the form is attached to also has an href attribute that normally links to the 'show' action for the resource in question so, I believe in this case it would be safe from prefetching.
But that is good to know in the case where one might be manually adding a _method=delete parameter to their links.
Rick Olson wrote:
Jim - My take: I recommend trying the REST route. It's useful even if
not doing XML or APIs. REST is a way of thinking about the design of
your application. It will make you think more tactically about how to
build a well designed app. And though it may feel constrained and
more difficult to design, I've found that working with a limited set
of "verbs" makes the resultant designs easier to understand and the
code easier to maintain and test. You end up with nice, small,
simple pieces of code that are each easy to understand and are solid
at doing their one thing well. New programmers looking at your code
(or you revisiting it later) find things right where you expect them
to be in a well-packaged, predictable manner. Take a look through the
Beast Forum source code (http://svn.techno-weenie.net/projects/beast/)
to see how nice a REST-ful approach can look. Also see:
http://www.therailsway.com/2007/2/13/signout-part-1 for notes from
Jamis Buck on "Why REST?". Try the REST-ful approach and I think
you'll find that Jamis's preference for REST is well founded.
