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
I’ve just been looking at REST as well and am about to try it out. One
shortfall I can see is that it uses client-side javascript. This means
any clients that can/will not run javascript can not use a RESTful rails
app. Or have I got this wrong?
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
Correction: javascript is only used for setting the http delete method.
On 8/15/07, Jesse C. [email protected] wrote:
Correction: javascript is only used for setting the http delete method.
Jesse C. wrote:
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.
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
–
Rick O.
http://lighthouseapp.com
http://weblog.techno-weenie.net
http://mephistoblog.com
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.
On 8/15/07, John L. [email protected] wrote:
I’ve just been looking at REST as well and am about to try it out. One
shortfall I can see is that it uses client-side javascript. This means
any clients that can/will not run javascript can not use a RESTful rails
app. Or have I got this wrong?
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.
Jesse C. wrote:
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.
Hi all,
Sorry for interrupting in your discussion…Iam facing one problem
in REST.
I am using REST for my api…so if user hits the http link in browser i
do some
validation and some process and i want to show them in xml output…
so output should be
<description
your mail sent successfully
if i use responds_to
in my controller i dont know how to show the above result…if any one
knows help me
Jesse C. wrote:
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
I am indeed referring to this. See
http://www.b-simple.de/documents/download/6 where it says in para 1.8.3
that Rails generates Javascript to handle the DELETE request. This
generates a hidden field called “_method” that contains the HTTP verb.
So, I suppose to handle DELETEs where Javascript is not there, you’d
have to manually add this hidden field in your HTML.
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 B. on “Why REST?”. Try the REST-ful approach and I think
you’ll find that Jamis’s preference for REST is well founded.
On Aug 16, 3:26 am, John L. [email protected]