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.