WHY Rest
pankaj
want to use it as a webservice.
If yes then why? What specific advantages would it offer?
Also if i plan to use it as a web service then, using ActiveResource
CRUD operations can be performed on the resources but suppose there is
another another action (eg Approve) in my controller. Is it possible
to access custom actions(approve) through Active Resource?
Pankaj
Ryan Bigg
link_to @topic.name, { :controller => "topics", :action => "view", :id => @topic.id }
when Restful Routing gives you:
link_to @topic.name, topic_path(@topic)
Anton J Aylward
> Is it enough to not type something as horrible as:
>
> :action => "view", :id => @topic.id <http://topic.id> }
>
> when Restful Routing gives you:
>
No, its not.
Unless you are _just_ dong a CRUD.
Anything with more complex actions (a wiki: search, attach, roll-back,
access control ...; a game: many functions!) you ARE going to have to
specify the actions and quite possibly the controller.
The benefits of Rest are far from clear.
Or perhaps I should say they are far from being stated well and clearly
and in a form that allows them to be applied situations beyond the basic
CRUD.
No doubt there are, to quote a famous novel and movie "minds superior to
(this) man's" that can and do use REST in more general situations.
Perhaps they could explain it to us duffers and newbies, then.
But to date, for all my drilling down ("google is you .. if not friend
then a least ally"), I find a lot of "its great stuff" from people who
have simplified applications but very little details of the "HOW".
--
The state can't give you free speech, and the state can't take it away.
You're born with it, like your eyes, like your ears. Freedom is
something you assume, then you wait for someone to try to take it away.
The degree to which you resist is the degree to which you are free...
--Utah Phillips
Jason Roelofs
map.resources :topics, :collection => {:search => :get} ). In my months of learning to do a more RESTful site, I've found out that it's not about making a web-service-like website, but more of what thinking RESTfully does to your design.
In short, RESTful web design is cleaner and much easier to understand. It keeps your controllers small and the logic seperated out. So instead of one massive WikiController, you'd have a WikiController, TopicController, AccountController, etc, which is much easier on: future developers of the product, people trying to bookmark parts of the wiki, the webserver for not having to deal with so much code at once, etc. It's just a good idea.
Give it a try, you'll see what I mean.
Jason
Amos King
restful way too. Then you have separated searching out from the other
controllers.
--
Amos King
A. King Software Development and Consulting, L.C.
http://dirtyInformation.com
--
Looking for something to do? Visit http://ImThere.com
Anton J Aylward
> Use a separate controller for searching. Then it can be place in the
> restful way too. Then you have separated searching out from the other
> controllers.
While that's plausible, I still don't see how it makes sense. Please see
may later reply to Jason. I don't see what advantage this has over
putting the search code in 'lib/search.rb'.
--
"Current economics is merely refining the obsolete. Economic theory is
still based on the scarcity axiom, which doesn't apply to information.
When I sell you a phone, I no longer have it. When I sell information
to you, I have more information by the very fact that you have it and I
know you have it. That's not even true of money."
-- Peter Drucker, WiReD6.03 Mar-1998
Anton J Aylward
>
> map.resources :topics, :collection => {:search => :get} ). In my
> months of learning to do a more RESTful site, I've found out that
> it's not about making a web-service-like website, but more of what
> thinking RESTfully does to your design.
>
> In short, RESTful web design is cleaner and much easier to
> understand. It keeps your controllers small and the logic seperated
> out. So instead of one massive WikiController, you'd have a
> WikiController, TopicController, AccountController, etc, which is
> much easier on: future developers of the product, people trying to
> bookmark parts of the wiki, the webserver for not having to deal
> with so much code at once, etc. It's just a good idea.
>
> Give it a try, you'll see what I mean.
I have and I don't.
Obviously I "don't get it".
I've plugged "restful authentication" into my wiki and that's fine
because its compartmentalized, but the rest of the wiki works entirely
on urls of the form
http://hostname.com/Webname/TopicName
with an optional "/:action" - edit, history ... you know the rest
(sorry, I can't resists puns)
Intrinsically there ARE methods. Strictly speaking there isn't even
CRUD, since editing a previously non existent topic causes its creation
and you don't 'delete' a topic you 'rename' it to the waste-bin Web.
So there's WikiController and no TopicController or WebController. (Oh,
there was when experimenting and as an admin interface, but they are
long gone, their function wasn't relevant to the wiki interface.)
The authentication function is completely orthogonal to the Wiki space
so having '/login' and '/register' is not an issue.
You say "RESTful web design is cleaner and much easier to understand"
but I don't see that. So many people say that and its getting to sound
like a "fashion" and "proof by assertion". As I've said, there are blog
postings where people claim this simplification by don't show the 'how'
and don't show it in a way that I can learn from the process.
Now and in the past I'm thinking in terms of what the application looks
like to the user. Navigating the wiki, the wiki's functionality is one
thing and the 'login/registration' is a "popup" (if only I could get
popups to work the way I want) in the workflow (aka "You need to login
to access this topic" type popups). This has led me to think in terms
of the routing and the mapping of the actions, of which there are many
beyond CRUD.
So, even if I somehow REST-ificate the WikiController, how do I decide
what GET/PUT are 'history', 'alter metadata', 'diff r1=n, r2=m', rename,
'search', 'upload', 'view attachment' and so on.
Please, I'm seeking a methodology and approach. I'd love to have a
simpler WikiController. I'd love to have a UiController that handles
the commonality of access control, dealing with exceptions and so on
(right now its 'lib/ui_wrapper.rb) that 'view', 'edit' and so on are
parameters for (modules?). But what value of WebController or
TopicController? (All I can see for them is web services to give lists
for 'rename'.)
I'm sorry, Jason, without some explanation it all seems like "proof by
assertion" or "the latest fashion" to me.
I'm finding this very frustrating since I can't see how this is relevant
to me without a lot of jigging the routing, like you illustrate, Jason.
At which point I say "Why bother? How is this different from what I'm
doing now with all the methods?"
--
Do you want the truth, or a well-designed machination brought
into existence solely for the stroking of your ego?
-- Empty <em...@theriver.com> on alt.goth
Anton J Aylward
> Use a separate controller for searching. Then it can be place in the
> restful way too. Then you have separated searching out from the other
> controllers.
??
And why not have separate controllers for 'edit' and 'tag' and 'attach'
and view' and ...
Sorry. I don't see it.
--
Never forget: The road to Hell is paved with good intentions.
So tread hard on good intentions. -- rjd4
Jeremy McAnally
is usually GET unless it's destructive (POST) or edits a resource
(PUT).
REST allows you to have a conventional layout to your controllers,
expose web services easily, get nice named routes in Rails (including
for your custom methods), and because of its conventional layout, you
can abstract it very easily (e.g., make_resourceful reduces the CRUD
portion of your controllers to 4 lines rather than 100).
If you're concerned about your URLs, then customize the routing.
There's nothing saying you can't have routing aliases for browser
clients of your RESTful actions so long as the RESTful one is still
available for web services.
--Jeremy
--
http://www.jeremymcanally.com/
My books:
Ruby in Practice
http://www.manning.com/mcanally/
My free Ruby e-book
http://www.humblelittlerubybook.com/
My blogs:
http://www.mrneighborly.com/
http://www.rubyinpractice.com/
Anton J Aylward
> You can add custom methods to a REST controller, and any custom method
> is usually GET unless it's destructive (POST) or edits a resource
> (PUT).
OK, so back to my wiki. The 'edit' is the only thing there, nothing
destructive.
> REST allows you to have a conventional layout to your controllers,
You don't mean '/views/layouts'? So what does 'conventional' mean in
this context? (more below)
> expose web services easily,
What if I don't HAVE them? Why bother?
> get nice named routes in Rails (including for your custom methods),
Let me try again: I don't WANT what I've seen as nicely named routes
I don't WANT URLs like
http://example.com/web/Webname/topic/TopicName
or 'id' instead of 'name'
As I said, apart from out-of-ban things like login its just
http://example.com/Webname/TopicName[?params]
> and because of its conventional layout, you
> can abstract it very easily (e.g., make_resourceful reduces the CRUD
> portion of your controllers to 4 lines rather than 100).
But I don't see what I'm trying to address as 'conventional CRUD'.
As I said at the beginning, I understand RESTfulnesss for that
invoice-item type, CRUD type applications, but there are a lot of web
based things that don't follow that model. Wikis and games being a few.
> If you're concerned about your URLs, then customize the routing.
I am. And its very simple. Just one line. (see above)
> There's nothing saying you can't have routing aliases for browser
> clients of your RESTful actions so long as the RESTful one is still
> available for web services.
Amos King suggested what seems to be mapping each method onto a
controller. That doesn't make sense to me either.
I can understand a Search Controller in the context of a page with a
form for the search parameters then submitted to that controller, but
its still drawing on the basic wiki functionality for rendering, so why
bother.
If a search is embedded in a page (see TWiki, Xwiki, MoinMoin and many
other wikis) then I can't see it being a web service instead of a
library utility. The Search Page calls this library too. So why bother
with the controller to move the code out of the WikiController?
If I have a search controller to move the search code out of the
WikiController (where it wasn't in the first place 'cos it was in a
library) the its only going to have one method.
So why, reductio ad absurdem, don't I convert everything that is a
method in the WikiController into a controller with one method, get rid
of the WikiController and do everything from
'app/controllers/Application.rb' ?
Let me ask all this another way.
I've asked this before in another wording and got no reply.
The user tries to 'view' a page. The WikiController's 'view' method
gets to the point where it finds the topic and checks accessibility.
Right now if a login is required to view that page it does a redirect
with return-to to the login page. Its irrelevant whether the login
mechanism is RESTful or not. I've installed 'restful authentication'
and its happy with the redirect & return-to, as was the old acts_as ..
with no RESTful-ness. So what's the benefit?
Please don't say 'extending functionality'. I pasted in code to do p/w
change into both versions of the authenticator with ease.
Can I do some magic pop-up with 'restful authentication' that I couldn't
with the old version? I've asked about that as well and again got no
reply. Wouldn't a popup authenticator be a 'web service' of some kind?
--
"I think there is a world market for about five computers."
Thomas J. Watson, chairman of the board of IBM, 1943
Michael D. Ivey
> I have and I don't.
> Obviously I "don't get it".
Just an observation: you seem really confrontational about REST.
That's going to make it hard to get people to answer you.
But, here's my take on it.
Following the RESTful patterns gives you immediate benefits and long-
term benefits.
Immediate benefits:
- Web services for basically free
- Cleaner controllers, although possibly more of them
- Easier maintenance for future developers, because of following
the conventions
Long-term benefits:
- By thinking in terms of resources, you end up composing your
application differently. Lots of people have found, through
real experience,
that this "different" is better, for them.
- ^^ this gets more and more obvious over time.
The reason you're getting lots of "try it, you'll like it" is because
this isn't an obvious "X is better than Y because Z". It's more,
"Man, I did Y, and I really felt like things went better than when I
did X."
If you want to honestly find out more about the experiences of people
who have used RESTful patterns and found value from them, I'm more
than happy to go into more detail.
Jeremy McAnally
> OK, so back to my wiki. The 'edit' is the only thing there, nothing
> destructive.
>
OK, so it's a GET request. A web service usually won't ever call edit
because it doesn't need a form; it will submit XML representations
straight to create/update.
>
> You don't mean '/views/layouts'? So what does 'conventional' mean in
> this context? (more below)
>
No, I don't.
>
> Let me try again: I don't WANT what I've seen as nicely named routes
> I don't WANT URLs like
>
> http://example.com/web/Webname/topic/TopicName
> or 'id' instead of 'name'
>
> As I said, apart from out-of-ban things like login its just
>
> http://example.com/Webname/TopicName[?params]
>
>
I don't mean on the front end; I mean things like `wiki_entry_path` or
`edit_user_path`. It makes your code MUCH cleaner.
> But I don't see what I'm trying to address as 'conventional CRUD'.
> As I said at the beginning, I understand RESTfulnesss for that
> invoice-item type, CRUD type applications, but there are a lot of web
> based things that don't follow that model. Wikis and games being a few.
>
Right, but if you have resources (e.g., entries, pages, users), then
you can use it. No one is forcing you to use it. It's just an
easier, cleaner way to structure your application.
>
> I am. And its very simple. Just one line. (see above)
>
OK, keep that line. Problem solved.
>
> Amos King suggested what seems to be mapping each method onto a
> controller. That doesn't make sense to me either.
>
> I can understand a Search Controller in the context of a page with a
> form for the search parameters then submitted to that controller, but
> its still drawing on the basic wiki functionality for rendering, so why
> bother.
>
> If a search is embedded in a page (see TWiki, Xwiki, MoinMoin and many
> other wikis) then I can't see it being a web service instead of a
> library utility. The Search Page calls this library too. So why bother
> with the controller to move the code out of the WikiController?
>
You don't have to. You can have a search method on WikiController.
Nothing is stopping you.
> Let me ask all this another way.
> I've asked this before in another wording and got no reply.
>
> The user tries to 'view' a page. The WikiController's 'view' method
> gets to the point where it finds the topic and checks accessibility.
> Right now if a login is required to view that page it does a redirect
> with return-to to the login page. Its irrelevant whether the login
> mechanism is RESTful or not. I've installed 'restful authentication'
> and its happy with the redirect & return-to, as was the old acts_as ..
> with no RESTful-ness. So what's the benefit?
>
> Please don't say 'extending functionality'. I pasted in code to do p/w
> change into both versions of the authenticator with ease.
>
> Can I do some magic pop-up with 'restful authentication' that I couldn't
> with the old version? I've asked about that as well and again got no
> reply. Wouldn't a popup authenticator be a 'web service' of some kind?
>
You're completely missing the point of REST. I'm not even sure what
you're asking there. The benefit of REStful Authentication is that
clients that aren't web browsers can create a session and access
resources just like a browser. The point is extending functionality
or something. It's giving things a structure that is consistent and
accessible by clients without a lot of overhead and complicated API.
ActiveResource is one such client. If I'm making a remote client to
your wiki, I will need to create an ActiveResource model for Session,
Entry, and so on. When I try to access an Entry that I don't have
permission for, your app will throw me a permission denied error.
Then my app will know to create a Session (through REST, mind you, so
using POST to create with the right params) and then continue on with
what it was doing. If this was a random RPC interface, I'd have all
kinds of socket madness going on and parsing of XML by hand and so on.
If you're not convinced by now, then perhaps you need to read a book
or article or just not worry about it. REST may offer no benefit to
you.
--Jeremy
Mark Wilden
a web service. Skinnier controls? Nonsense. Model stuff should go in
the model - it doesn't matter whether you're using REST.
The thing is, though, that almost all the smart people I know like
REST. That's indicative, and I'm going to try to keep an open mind.
But at one point I made up my mind to convert my app to REST, and I
couldn't for the life of me see any justification for doing the work.
I'm definitely missing something. :)
///ark
Jeremy McAnally
RESTful app far faster than I could write a "regular" CRUD
application.
Maybe it's just because I'm used to it now or something.
--Jeremy
--
Mark Wilden
wrote:
> I don't see what extra work you were having to do
should do it anyway, then maybe I'd get a better feel for REST's
advantages. But at the time, I couldn't see a justification for doing
that work instead of putting the time toward some other facet of the
app. But thanks for the push. I'll convert it today. Should take like
an hour, tops?
///ark
Anton J Aylward
Thank you so much, Mark.
You've expressed a few points that I've omitted.
--
If God had intended Man to Watch TV, He would have given him Rabbit Ears.
Anton J Aylward
> It's just an
> easier, cleaner way to structure your application.
OK, but HOW?
--
Skill without imagination is craftsmanship and gives us many useful
objects such as wickerwork picnic baskets. Imagination without skill
gives us modern art.
-- Tom Stoppard
Anton J Aylward
>
>> Let me try again: I don't WANT what I've seen as nicely named routes
>> I don't WANT URLs like
>>
>> http://example.com/web/Webname/topic/TopicName
>> or 'id' instead of 'name'
>>
>> As I said, apart from out-of-ban things like login its just
>>
>> http://example.com/Webname/TopicName[?params]
>
> I don't mean on the front end; I mean things like `wiki_entry_path` or
> `edit_user_path`. It makes your code MUCH cleaner.
'Named routes'?
Surely you don't need RESTful design for that.
I have named routes anyway.
--
If the errors of the past were good enough for
our ancestors, they re good enough for us!
Anton J Aylward
> On Jan 4, 2008, at 9:03 AM, Anton J Aylward wrote:
>> I have and I don't.
>> Obviously I "don't get it".
>
> Just an observation: you seem really confrontational about REST.
I'm sorry if I seem confrontational; I'm just frustrated on a number of
counts.
Over the past months I've asked more specific questions that are related
to this and not got any answers. None.
And as I say, I see plenty of "isn't it great" postings in blogs but
very little that actually explains how to transform anything beyond a CRUD.
And it all seems to be coming out at once.
Surely I can't be the only person so afflicted?
--
It is against the grain of modern education to teach children to
program. What fun is there in making plans, acquiring discipline in
organizing thoughts, devoting attention to detail, and learning to be
self-critical?
-- Alan Perlis
Jeremy McAnally
Why _not_ use them?
--Jeremy
--
Anton J Aylward
> No but you get a bunch of them generated for free.
>
> Why _not_ use them?
I could say 'defensive programming'.
The named routes aren't explicit, as I understand it.
A malicious user could experiment with dynamically generating routes.
A fat fingered typist (I'm one, so I know!) could use typos as routes
that are incompatible with other parts of the code.
I favour pushing back the checks. Routing seems a good place to say
what is and isn't permitted.
--
Right now I'm having amnesia and deja vu at the same time. I think I've
forgotten this before.
Michael D. Ivey
> I'm sorry if I seem confrontational; I'm just frustrated on a
> number of
> counts.
No worries. I wasn't sure you could tell, and I want to help you
figure this out. I figured other people may have been having the
same reaction I was.
> Surely I can't be the only person so afflicted?
I hope not...you're all the market for my eBook that I haven't
written! :)
Sazima
Your answer was very sensible and I would like to hear more from you.
I can see some of the benefits, but nothing REALLY interesting so
far...
Cheers, Sazima
Gregory Seidman
>
> Michael D. Ivey said the following on 04/01/08 11:58 AM:
> > On Jan 4, 2008, at 9:03 AM, Anton J Aylward wrote:
> >> I have and I don't.
> >> Obviously I "don't get it".
> >
> > Just an observation: you seem really confrontational about REST.
>
> I'm sorry if I seem confrontational; I'm just frustrated on a number of
> counts.
>
> Over the past months I've asked more specific questions that are related
> to this and not got any answers. None.
>
> And as I say, I see plenty of "isn't it great" postings in blogs but
> very little that actually explains how to transform anything beyond a CRUD.
>
> And it all seems to be coming out at once.
>
> Surely I can't be the only person so afflicted?
You are not alone. I have not been particularly impressed with REST as a
design paradigm for anything other than web services. While there are
certainly advantages to being able to create web services simply and
easily, I do not believe that good URL design for web services is the same
as good URL design for user-facing sites. Conflating RESTful web services
with good user interface doesn't make sense to me.
I might feel differently about it if the class of webapps I develop leaned
more toward Twitter or the like, but I typically create custom web
applications for nontechnical clients. There are requirements involving how
the site is laid out and how it feels to be a user, and no concern about
web services.
I'd like to hear some compelling arguments about why RESTful Rails
development matters even if web services are completely off the table, but
so far all I've heard is about how thinking of things as resources makes
for a nice design, which I'm not buying (see above).
--Greg
Peter De Berdt
I could say 'defensive programming'.
The named routes aren't explicit, as I understand it.
A malicious user could experiment with dynamically generating routes.
A fat fingered typist (I'm one, so I know!) could use typos as routes
that are incompatible with other parts of the code.
I favour pushing back the checks. Routing seems a good place to say
what is and isn't permitted.
Best regards
Peter De Berdt
Brian Hogan
Anton J Aylward
>>
>> Surely I can't be the only person so afflicted?
>
> You are not alone. I have not been particularly impressed with REST as a
> design paradigm for anything other than web services. While there are
> certainly advantages to being able to create web services simply and
> easily, I do not believe that good URL design for web services is the same
> as good URL design for user-facing sites. Conflating RESTful web services
> with good user interface doesn't make sense to me.
Good point.
As in "I wish I had said that".
Things like games and wikis ARE the user interface, in many ways.
> I might feel differently about it if the class of webapps I develop leaned
> more toward Twitter or the like, but I typically create custom web
> applications for nontechnical clients. There are requirements involving how
> the site is laid out and how it feels to be a user, and no concern about
> web services.
Yes, that applies to Wikis, and to the games I've seen and used.
> I'd like to hear some compelling arguments about why RESTful Rails
> development matters even if web services are completely off the table, but
> so far all I've heard is about how thinking of things as resources makes
> for a nice design, which I'm not buying (see above).
--
Expecting life to treat your fairly because you are a good person is
like expecting an angry bull not to charge because you are a vegetarian.
-- Shari R Barr
Rick DeNatale
> Here's how REST makes sense though, and this is NOT made clear by Rails:
>
> Resources are NOT models.
>
> I built a simple system to control the lights in my house. I did it with
> REST. I ended up with two resources:
>
> a Unit, which is the resource to manage the creation, deleetion and
> modification of the X10 devices in my house.
>
> When the time came to actually turn on a light switch or turn it off, my
> first instinct was to add the following code to the Unit controller:
>
> def on
> @unit = Unit.find_by_id(params[:id]).on!
> end
>
>
> def off
> @unit = Unit.find_by_id(params[:id]).off!
> end
>
>
> But after thinking about it, what I'm doing is changing the STATE of the
> unit. Therefore, it made more sense to have a State resource.
...
> Notice how the state resource changed how I implemented the code to
> manipulate the light? Interesting stuff.
>
> This also made me realize that the show action (get) could tell me the
> current state of the light.
>
> Already I have less complicated controllers, though I have more.
>
>
> That's just my .02. :) I did a fun project to learn more about how REST can
> help me design things. I can share some code if anyone cares.
YEP! It's not so much the url structure as the view of controllers as
resource controllers that's important.
I got the same kind of epiphany from building one or two NEW
applications in rails 2.0 using rails view of restful design. It's
one of those paradigm shifts that you have a hard time getting until
you do.
And I think that the epiphany is more likely to come from trying a new
fairly simple app using REST than by struggling through converting an
existing one. After the epiphany you're much more likely to
understand what such a conversion really entails and how to do it
successfully.
--
Rick DeNatale
My blog on Ruby
http://talklikeaduck.denhaven2.com/
Peter De Berdt
I'd like to hear some compelling arguments about why RESTful Rails
development matters even if web services are completely off the table, but
so far all I've heard is about how thinking of things as resources makes
for a nice design, which I'm not buying (see above).
Anton J Aylward
>
> You don't have to. You can have a search method on WikiController.
> Nothing is stopping you.
Nothing is stopping me making system calls to custom C-code either, but
that's not the point.
I'm trying to ask HOW I can re-structure things to take advantage of
REST. I'm repeatedly told its 'good for you' but short on the HOW.
Lots of the hints don't make sense. A search method in the
WikiController could just as easily be a web service.
You go on to say
> You're completely missing the point of REST.
Yes, and its not the benefits I'm asking about, its the HOW.
Not the technical HTTP level how, but the code organization how.
And yes, I've read a lot about it and its stirred my interest, but its
still not telling me anything I can see how to USE. And by 'use' I mean
how to structure my code design to make sense and make use of it.
Because replacing what is now a method with a controller doesn't make
sense - not to me, and not unless there is some advantage that you guys
see that I don't and hasn't been stated. And thinning down the
WikiController isn't the advantage 'cos all the code is in
'lib/search.rb'.
Let me give an example of what I mean by the HOW.
A blog, sorry can't find it in my bookmarks quickly, suggested a skinny
controller full of 'def action end' and the code in the models views and
helpers. Well I managed to make one with all the code in the helpers.
Lots of DRY; the helper was really a 'library' for the 'calls' in the views.
The examples of RESTfulness I've seen, with the exception of 'restful
authentication' (and questions about that have gone unanswered) all seem
to focus on CRUD and the kind of routing I very much DO NOT want to use.
They really do not communicate any advantage. But so what; I've seen
code fragments that show Perl and PHP outperform Ruby - perhaps they do,
in fragments, but at the level of whole applications where the code is
in Ruby-idioms rather than merely translating Perl, then Ruby performs
at least as well as Perl.
I had to learn the Ruby idioms, and now I prefer Ruby to Perl. So I can
accept it when Jeremy says he can write RESTful apps fluently.
What I don't see is the HOW for anything but the basic CRUD.
Suppose I do that 'SearchController with one method' change, and work
though the changes to the routes (!?!). What do I do next? I can't
keep coming back here and asking 'what do I do next'. I need to
understand the HOW to convert (or redesign). That's what I'm seeking to
find out. And its why I'm frustrated by people simply telling me that
RESTfulness is a good thing.
--
Genius may have its limitations, but stupidity is not thus handicapped.
Elbert Hubbard
Rick DeNatale
>
> I need to
> understand the HOW to convert (or redesign). That's what I'm seeking to
> find out. And its why I'm frustrated by people simply telling me that
> RESTfulness is a good thing.
As I just tried to point out in a recent reply to this post, it's
probably better to learn how to first design using restful principles
for a simple new app before trying to re-design an existing app.
One small starting point might be to really understand the differences
between code generated by the the acts_as_authenticated and
restful_authentication plugins. Although that's probably too small an
'app' to demonstrate the benefits of going from a few complex
controllers to more but much simpler ones.
George Bailey
Clearly this is a book asking to be written. That it hasn't yet
appeared tells me that not many people (or at least not the right
ones) have a strong enough and solid grasp of it to write that book,
even if they personally know that it's a useful idea.
In the software development race I'm a tortoise. I plod along until
the next step has been clearly explained by one of the smart hares who
have figured it out. So while I feel a tinge of guilt that my app is
not RESTful and my controllers fat, it's not yet enough to get my
tortoise-behind to make the change.
And I don't worry that my current application will later seem
antiquated and in need of a massive rewrite - every program I've ever
written could benefit from a rewrite, and I expect that to always be
true for me, and usually true for almost everybody else as well.
Daniel Waite
> What I don't see is the HOW for anything but the basic CRUD.
You keep harping on "basic CRUD." As if "basic CRUD" applications cannot
be complex.
It might help you to watch this video of DHH explain his new-found love
for CRUD:
Also, I thought Brian Hogan did a pretty good job of explaining the
elusive "how."
Post: http://www.ruby-forum.com/topic/137572?reply_to=612281#612265
I'll reiterate what I find to be his most important part: Resources are
_not_ models.
Imagine a collection of clients. We can create, read, update and delete
those resources (forget that you may have an actual client model as
well).
But what about searching for clients? That doesn't seem to fit the CRUD
model. Except it does.
If we twist our brains, we might come up with a ClientSearches resource.
Notice I said resource. That means another controller. No new models
though. Just a different way of looking at our model.
With ClientSearches in our brains, it _does_ make sense to CRUD it. When
we perform a search we are _creating_ a new search.
That's REST.
I think someone else in this thread mentioned that a single resource
doesn't have to be restricted to one model. If I have an Account
resource, I could use the show method to display a Company object, all
their Client objects, and maybe even some Contact objects. Remember:
resources are not objects.
Also, REST is not limited to CRUD. You can easily define other actions
in your controllers provided the actions they carry out are respective
to their HTTP method. In Rails 2 (possibly lower versions, not sure) you
can specify a new custom route onto a map.resources command.
See this pod cast for more on that:
http://railscasts.com/episodes/35
Hope that helps answer the "how" portion of your question.
- Daniel
--
Posted via http://www.ruby-forum.com/.
Daniel Waite
> It might help you to watch this video of DHH explain his new-found love
> for CRUD:
Oops, here's the video:
http://www.scribemedia.org/2006/07/09/dhh/
Michael Schuerig
> If we twist our brains, we might come up with a ClientSearches
> resource. Notice I said resource. That means another controller. No
> new models though. Just a different way of looking at our model.
I don't see the problem with searching at all and therefore may be blind
for what this solution offers, but I can't imagine why I would model(!)
searching as creating a resource.
What's wrong with
GET /clients?firstname=John&lastname=Doe
and handling it in ClientsController#index?
Michael
--
Michael Schuerig
mailto:mic...@schuerig.de
http://www.schuerig.de/michael/
Ryan Bigg
Clearly this is a book asking to be written. That it hasn't yet
appeared tells me that not many people (or at least not the right
ones) have a strong enough and solid grasp of it to write that book,
even if they personally know that it's a useful idea.
In truth, restful routing is plain and simple. It's like those books you wrote when you were a kid in kindergarten that if a book critic were to read them he would jab his eyes out with a pen.
For this example I'm going to use a personal favourite: a forum system. It's small enough to not be overwhelming, yet large enough to explain how restful routing should work (and generally why you should use it).
It all starts with the good 'ol config/routes.rb file. In here is where all the nice little routes live, from map.root all the way down to the map.connect ':controller/service.wsdl', :action => 'wsdl' that many people still leave in their routes file, thinking that if they remove it the entire world would collapse upon itself into one small quantum singularity. In here you'd place something similar to:
map.resources :forums, :has_many => :topics
map.resources :topics, :has_many => :posts
map.resources :posts
Not running on Rails 2.0? Then this is the code you want:
map.resources :forums do |forum|
forum.resources :topics, :name_prefix => "forum_"
end
map.resources :topics do |topic|
topic.resources :posts, :name_prefix => "topic_"
end
map.resources :posts
This defines routes like:
/forums/1 <- Show a forum
/forums/1/topics <- Index action for a single forum
/forums/1/topics/1 <- showing a single topic
/topics/1 <- Same thing
/topics/1/posts/ <- I would imagine this would do a similar thing to /topics/1
/topics/1/posts/1/edit <- Allows you to edit a single post
/posts/1/edit <- Same thing
Now to define something like this without the magic of restful routing, one would have to be clinically insane:
map.connect "/forums/:id", :controller => "forums", :action => "show"
map.connect "/forums/:forum_id/topics/", :controller => "topics", :action => "index"
map.connect "/forums/:forum_id/topics/:id", :controller => "topics", :action => "show"
map.connect "/topics/:id", :controller => "topics", :action => "show" <- Does this look familar to /forums/:id?
map.connect "/topics/:topic_id/posts", :controller => "posts", :action => "index"
map.connect "/topics/:topic_id/posts/:id/edit", :controller => "posts", :action => "edit"
map.connect "/posts/:id/edit", :controller => "posts", :action => "edit"
And this is only the tip of the iceberg!
Seeing a pattern here? Restful routing gives you a whole heap of cool stuff, namely the 7 core methods that I'll cover right after the models.
A forum system has the following tables: forums, topics, posts and users, and the models would look something like the following:
class Forum < ActiveRecord::Base
has_many :topics
has_many :posts, :through => :topics
end
class Topic < ActiveRecord::Base
has_many :posts
belongs_to :forum
belongs_to :user
end
class Post < ActiveRecord::Base
belongs_to :topic
belongs_to :user
end
class User < ActiveRecord::Base
has_many :topics
has_many :posts
def to_s
login
end
end
The fields don't matter, but throughout the tutorial I make reference to @ forum.name or something similar, so we'll assume forums has at least a name field. We'll assume post has a text field and users has a login field.
That'll give you some idea of how the system works: Forum -> Topics -> Posts.
In restful routing there are seven "core" methods (actions) that you're given for the controllers: index, show, new, create, edit, update, destroy. Each of these have a set request method on them, for example you can't GET to the create, update and destroy actions and you can't post to the index, new or edit actions. These actions work with these request methods:
GET: index, show, new, edit
POST: create
PUT: update
DELETE: destroy
"What the?! PUT & DELETE, where did they come from?", I hear you cry! These are hacked into the calls for the appropriate action using javascript, it passes in one more parameter (_method) which is then handled by the rails code and depending on what method you called you will get the page you were looking for, or a routing error.
The forums controller could look like this:
class ForumsController < ApplicationController
def index
@forums = Forum.find(:all)
end
def show
@forum = Forum.find(params[:id])
end
def new
@forum = Forum.new
end
def create
@forum = Forum.create(params[:forum])
flash[:notice] = "You have created a forum!"
redirect_to forums_path
end
def edit
@forum = Forum.find (params[:id])
end
def update
@forum = Forum.find(params[:id])
@forum.update_attributes(params[:forum])
flash[:notice] = "You have updated #{@forum.name }"
redirect_to forum_path
end
def destroy
@forum = Forum.find(params[:id])
@forum.destroy
flash[:notice] = "You have deleted #{@forum.id}"
redirect_to forums_path
end
You'll see here that I've twice made a call to redirect_to using the argument of forums_path. Because we've defined map.resources :forums in our config/routes.rb file, it knows that we want to go to { :controller => "forums", :action => "index" } and the best part is that we don't have to keep trying { :controller => "forums", :action => "index" } every time we want to go to that specific action, but instead we type forums_path.
I've also made a single call to forum_path, and I haven't specified an argument for it, so how does Rails know that I want to go to the forum that I just updated?
Rails will see that there's an argument mission from the forum_path and will go looking for the @forum instance variable you've defined in your controller. If you never defined one or defined it as something other than @forum, it will mention something about ambiguous routes and you'll have to specify the variable.
Now what if you wanted to go to the new or edit action? Simple: new_forum_path and edit_forum_path(@forum) will take you to the corresponding actions. Remember that you don't need to specify an argument for the edit_forum_path if @forum is defined. Inside these actions you'll want to go further, you'll want to create a new forum and update a forum.
For the create action you could specify this for your form:
Rails 2.0:
form_for @forum do |f|
Rails 2.0 will see that @forum is a new record and link you the create action.
Pre Rails 2.0:
form_for :forum, @forum, :url => forums_path do |f|
Prior to Rails 2.0 that checking wasn't in, you'll have to define your own link.
"B-b-b-ut", you stammer, "you've linked to the forums index, right? Isn't that what forums_path is?"
Well, yes and no. This has everything to do with the four request methods mentioned previously, because the form's method attribute is "post", Rails knows that if you're posting to forums_path, you mean the create action. And now for the update action!
Here the form_for's a little different (for Pre-Rails 2.0):
Rails 2.0:
form_for @forum do |f|
Again the same deal applies: Rails 2.0 knows that @forum is not a new record, so it'll link you to to the update action because it's included in a form. This automatically specifies :html => { :method => :put } for you.
Pre Rails 2.0
form_for :forum, @forum, :url => forum_path(@forum), :html => { :method => "put" } do |f|
It knows to link you to the update action because of the method => "put" we've specified.
Now lets escape from the confines of a single controller and bring the topics controller into the mix. In the forum show action is where you would generally show all the topics for that forum, but for the purposes of this tutorial I will do it in the topics controller instead. This will have something similar defined to the forums controller but personally I would define this for the controller:
class TopicsController < ApplicationController
before_filter :get_forum
def index
@topics = @forum.topics
end
#other actions
private
def get_forum
@forum = Forum.find(params[:forum_id]) if params[:forum_id]
end
The private call makes any method after it private, that means that if you were to try and access this method (without restful routing), it would play dumb. Personally I think something like this should be in-built to Rails, if you're accessing a child object (topics) from a parent (forum) it should automatically define @forum for you.
Because we've already defined the :has_many topics on map.resources :forums, the topic routes are already defined for us, so to view all the topics for a forum, before you would have to do define a route like this:
map.connect "/forums/:forum_id/topics/", :controller => "topics", :action => "index"
and then calling it like this:
{ :controller => "topics", :action => "index", :forum_id => @ forum.id }
Instead you've already defined :has_many :topics, so instantly you'll gain access to forum_topics_path. Again the wonderful Rails will realise that you want all topics for the @forum object and then direct you to "/forums/1/topics/" through forum_topic_path. To edit a single topic, you could do edit_forum_topic_path as of Rails 2.0, or forum_edit_topic_path prior to Rails 2.0. The first reads more like "edit this topic belonging to this forum" where the second reads like "in this forum, edit this topic". Alternatively you could ditch the whole forum part out of the method call and just do edit_topic_path because we've defined map.resources :topics.
Throwing one more controller into the mix now, called posts_controller. This would be very similar to the topics controller but instead of get_forum it would have get_topic, modified correctly.
Now what if you wanted to add a custom action to posts_controller, called quote? This action would bring up a form with the post you were quoting which would then send the information from the form into posts/new to create a new post:
In config/routes.rb:
map.resources :posts, :member => { :quote => :get }
The extra argument of :member indicates a hash of any further actions and their request methods you would like to be added onto singular posts. You can call these like all the other singular methods: quote_post_path(@post), for example. The request methods can be in string or symbol format, it doesn't matter.
def quote
@old_post = Post.find(params[:id])
@post = Post.new
@post.text = "[quote='#{@old_post.user}']#{@old_post.text}[/quote]"
render :action => "new"
end
Here I've defined the old post only to get the text and the user's name from it, and then we're rendering the new view so we have the form. Everything from there on is taken care by Rails.
Now what if you want to define a new action to work with a group of posts? Well you define it like this:
routes.rb
map.resources :posts, :member => { :quote => :get }, :collection => { :destroy_all => :delete }
Now if you wanted to destroy all posts for a topic, bar the first one, with an action like this (remembering @topic is defined in get_topic):
posts_controller.rb
def destroy_all
@posts = @topic.posts - @topic.posts.first
@posts.each { |post| post.destroy }
flash[:notice] = "All posts have been deleted.
end
You would link_to it like this:
link_to "Delete all posts", destroy_all_topic_posts_path(@topic), :method => "delete", :confirm => "Are you sure you want to delete all posts from this topic?"
The :method => "delete" corresponds with the :delete_all => :delete we specified in config/routes.rb.
That's it for now. If it still isn't clear how awesome restful routes have, then please state why, as I would love to know.
--
Ryan Bigg
http://www.frozenplague.net
Feel free to add me to MSN and/or GTalk as this email.
Daniel Waite
> On Saturday 05 January 2008, Daniel Waite wrote:
>> If we twist our brains, we might come up with a ClientSearches
>> resource. Notice I said resource. That means another controller. No
>> new models though. Just a different way of looking at our model.
>
> I don't see the problem with searching at all and therefore may be blind
> for what this solution offers, but I can't imagine why I would model(!)
> searching as creating a resource.
>
> What's wrong with
>
> GET /clients?firstname=John&lastname=Doe
>
> and handling it in ClientsController#index?
Interesting. I never said there was a problem. And there's certainly
nothing "wrong" with your approach.
Some things are better learned through experience. For me, REST was
certainly one of them. Perhaps the same is true for you.
At this point I'd strongly suggest that if you _really_ want to
understand the how and why, you do it for yourself.
Obviously I hope you try the RESTful lifestyle and love it, but if you
don't, no hard feelings. =)
Nathan Esquenazi
get a blog / post that on a blog rather than on this forum. The
formatting on this forum is atrocious and I would really like to be able
to refer back to this later.
Anton J Aylward
I'll look up the video when I get my codecs working, but ...
> I'll reiterate what I find to be his most important part: Resources are
> _not_ models.
OK, not a problem. See below.
> Imagine a collection of clients. We can create, read, update and delete
> those resources (forget that you may have an actual client model as
> well).
>
> But what about searching for clients? That doesn't seem to fit the CRUD
> model. Except it does.
For some values of 'fit'. See below.
> If we twist our brains, we might come up with a ClientSearches resource.
> Notice I said resource. That means another controller. No new models
> though. Just a different way of looking at our model.
>
> With ClientSearches in our brains, it _does_ make sense to CRUD it. When
> we perform a search we are _creating_ a new search.
No.
You're confusing an artefact of the language with the abstraction.
In Ruby you have to deal with classes and hence you have to do a 'new'.
If you look at the code base for TWiki you'll see they've made
everything an object. To do a save you hand the string to an object
that is the instance of the StorageManager rather than writing to a
file. There are lots of such objects. The startup code is full of
$this->{part} = new TWiki::Part( $this )
as the various parts (implemented as objects) are instanced and
references to them kept in one big 'context' object, and all further
operations indirect though that.
It makes the code ugly. Well uglier than Perl code needs to be. But
that's Perl and objects for you.
I point this out because a language in which each 'thing' is an object
can't be used (aka its methods) until you create an instance of that
object. Ruby is such a language. It doesn't matter if the Search class
is a controller or a library, you still end up doing
s = Search.new( ... )
You've made a 'virtue out of a necessity'. Of course we're creating a
new search. But that has nothing to do with a resource being a design
decision.
I've seen the likes of 'search' implemented many ways. With Ruby's
light-weight objects it makes sense to load stuff at create time.
In TWiki's Perl, there's just the one search engine for each context
(aka thread) so its completely parametrized when its invoked:
$this->{search} = new TWiki::Search( $this ) # 'new' per session
.....
$text = $this->{session}->search->searchWeb( .. huge argument list ...)
Now THAT is a design decision. That it is ugly and ungainly is an
artefact of the language!
So whether the design decision loads up at the time the search object is
instanced or when its method is invoked IS a design decision. You can
see a permutation on this with the use of the BruteMatch method used for
searching in the Socks-Wiki, another Ruby Project from before Rails.
The loading of the patterns and the search space are very spread out and
obscure, since, one again, the single engine is instanced into a context
object.
But unless you call the instantiation of the search object a
'create/INSERT//Post', and its going poof! when it goes out of context
and becomes a candidate for the garbage collector as a
'delete/DELETE/Destroy' there's not going to be a lot of methods. As
far as I can see a 'new()' and a 'do_the_search()'. No CRUD in it.
Or did I blink and miss something?
> That's REST.
See below.
> I think someone else in this thread mentioned that a single resource
> doesn't have to be restricted to one model.
Indeed. No argument, but that's a design an decision that is
independent of REST. My WikiController handles both the Web and the
Topic models in one gulp. If you look at Instiki, it does the same, and
updates other models that keep track of links and cross references.
While I'm mentioning it, would you call Instiki 'RESTful'?
If not, why not, and if so, why so.
> If I have an Account
> resource, I could use the show method to display a Company object, all
> their Client objects, and maybe even some Contact objects.
If I'm looking at a page in an address book the Person might have any
number of addresses and phone numbers. (Don't you hate the things like
ACT where there's only a fixed number of slots for phone numbers because
they are part of the Person record and not a separate 'has many' object.)
> Remember: resources are not objects.
Or at least they need not be. See 'restful authentication'.
> Also, REST is not limited to CRUD. You can easily define other actions
> in your controllers provided the actions they carry out are respective
> to their HTTP method. In Rails 2 (possibly lower versions, not sure) you
> can specify a new custom route onto a map.resources command.
>
> Hope that helps answer the "how" portion of your question.
No, if anything it leaves me more confused than before, for the simple
reason I'm doing most of that without anything looking what I've seen
described as RESTful.
My wiki has a controller that has no model behind it and my models don't
have corresponding controllers. The Wiki is the resource the user sees.
The webs and the topics in them aren't resources, they are content.
In fact I get puzzled why forums and blogs do nested routing.
If you look at the URL
http://reclusive-geek.blogspot.com/2006/11/peepcodes-restful-rails.html
there isn't a month controller in the year controller. The URL is
user-friendly, its not
/year/2007/month/11/post/peepcodes....
And since there's a lot of 'old code' that works this way its not a
feature of RESTfulness.
In fact the only controller in my wiki that that has a model behind it
or model with corresponding controller is the 'User' and that's
'restful authentication' and that has
new create activate
suspend unsuspend destroy
purge change_password forgot_password
reset_password find_user
And a deal of that was pasted in from 'acts_as_authenticated' and 'state
machine' as you can see. And I kept the named routes as well. So I'm
not bothered by 'beyond the CRUD'. Is this a 'fit the CRUD model'? I
wouldn't call it that. Not without squinting. I could remove the
'destroy' and 'purge' since there's no button on any of the views that
leads to them and its not part of the functionality. A user gets
suspended but the record is still there so that authorship can be
attributed. That's part of being a Wiki. I could delete those methods;
perhaps T should :-). And the login process don't offer a 'find' to the
user interface. You have to know the name or the activation code. So
its C-U-.
I have a (single) custom route for the wiki that doesn't involve any
'nesting' as there is only one relevant controller - the WikiController.
See above and previous postings. The 'restful controller', however,
uses lots of custom routes.
Sorry if this seems argumentative, but I'm trying to explain why I'm
saying "no it doesn't help explain the HOW'. Either I'm doing RESTful
design (and always have) without RESTful routing and without knowing it,
or there's something I'm not getting here.
--
The whole art of teaching is only the art of awakening the natural
curiosity of young minds for the purpose of satisfying it afterwards.
Anatole France (1844 - 1924), The Crime of Sylvestre Bonnard
Michael Schuerig
But you appear to suggest that my approach is somehow not RESTful. I'd
take exception to that and claim that, yes, what I suggest is
completely in line with REST. And it is my understanding that the
authors of "RESTful Web Services" (Leonard Richardson & Sam Ruby)
agree. I highly recommend that book.
jimmyz
> Unless you are _just_ dong a CRUD.
>
> Anything with more complex actions (a wiki: search, attach, roll-back,
> access control ...; a game: many functions!) you ARE going to have to
> specify the actions and quite possibly the controller.
It seems that the REST philosophy is all about breaking things down to
where you can handle everything with CRUD.
For example, instead of an action 'search' you might create a resource
of SearchResult, which you would only need to Read (GET). Even though
it wouldn't make sense to perform the other CRUD operations on a
SearchResult, you have still transformed it to focus on an object or
resource. For attaching an article, rather than having an 'attach'
method for Articles, you would have an ArticleAttachments, on which
you could do all of your CRUD.
The presentation found at RailsEnvy "The Future of Web
Services" (http://www.railsenvy.com/2007/12/17/the-future-of-web-
services) gives some good examples of 'how' to make this switch. This
is found in the last 3rd of the presentation. It also addresses
benefits of a RESTful approach as it relates to web services.
I'm still not converted to the RESTful approach for plain web
applications but maybe it's because I haven't followed the "do it and
you'll see" advice yet. It seems to me that the a user doesn't or
shouldn't care about the Model behind your web application, so it
seems following a CRUD approach for everything will lead to bad user
interface design. I think this relates to Jamis Buck's blog post
"Scaffolding's Place" (http://weblog.jamisbuck.org/2007/1/26/
scaffolding-s-place).
I suppose I could still start the design from the user interface and
build the application in a RESTful manner. Maybe it's just a matter of
organizing which interfaces belong to which controller. This seems
like it would require a lot of going out of my way to make my
application RESTful, but like I said, I haven't really tried out the
RESTful application design approach yet, so I may be wrong.
What do you think?
--
Jimmy Z
Brian Hogan
Brian Hogan
rsc...@gmail.com
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
voodoorai2000
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 :) 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 :) 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 http://yousite.com/rates I don't need to
know anything else to access your data and add it to my site. I
already now http://yousite.com/rates.xml 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 http://yousite.com/rates/new 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 :) Rails has brought happiness to my life,
and REST has brought even more happiness to me and my co-workers,
thing about them too :)
Hope that helps
Raimond Garcia
On Jan 4, 10:12 pm, Peter De Berdt <peter.de.be...@pandora.be> wrote:
> On 04 Jan 2008, at 21:49, Anton J Aylward wrote:
>
> > I could say 'defensive programming'.
> > The named routes aren't explicit, as I understand it.
> > A malicious user could experiment with dynamically generating routes.
> > A fat fingered typist (I'm one, so I know!) could use typos as routes
> > that are incompatible with other parts of the code.
>
> > I favour pushing back the checks. Routing seems a good place to say
> > what is and isn't permitted.
>
> All of this has nothing to do with REST. Basically what REST does
> (and I'm going to simplify things a bit), is express your public
> model and relationship structure in the url. In essence, REST doesn't
> even dictate how URLs have to be formed, it's a Rails convention to
> do it the way it's done.
>
> I like my urls to reflect (part of my) model structure in a logical
> way. It guides you in where to put your methods, e.g. if it has to do
> with manipulating and article, i should put it in the articles
> controller. Having the basic crud operations use a convention is a
> nice bonus. Some people like to structure their controllers logically
Michael D. Ivey
> 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.
Alfons Grabher
> 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
Peter De jong
Pat Maddox
>
> If I know you have a site about car rentals with all the
> rates in xml form at the url http://yousite.com/rates I don't need to
> know anything else to access your data and add it to my site. I
> already now http://yousite.com/rates.xml will give me all your rates
> in xml form, and adding them to my database is trivial.
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
Jeremy McAnally
ActiveResource. You could reflect on it like ARec, but I get your
meaning. :)
--Jeremy
--
http://www.jeremymcanally.com/
My books:
Ruby in Practice
http://www.manning.com/mcanally/
My free Ruby e-book
http://www.humblelittlerubybook.com/
My blogs:
http://www.mrneighborly.com/
http://www.rubyinpractice.com/
Mark Wilden
>
> 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.
semantics can be obtained by inspection.
///ark
Bharat
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
Anton J Aylward
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.
--
The deepest sin against the human mind is to believe things without
evidence.
Thomas H. Huxley
Anton J Aylward
>
> 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.
--
If you are using Windows 2000, there is no chance that DES is your
weak link. The only justification for using 3DES is that it is cheap.
-- William Hugh Murray, CISSP
Anton J Aylward
>
> 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: http://norvig.com/Gettysburg/
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 :) 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 :) 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 http://yousite.com/rates 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
____ ___ ____ _ _
__/\__/ ___|_ _/ ___| | | |_/\__
\ /\___ \| | | _| |_| \ /
/_ _\ ___) | | |_| | _ /_ _\
\/ |____/___\____|_| |_| \/
--
There are only 10 kinds of people in the world:
Those who understand binary, and those who don't.
Nathan Esquenazi
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.
Jason Roelofs
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.
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
Brian Hogan
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.
Anton J Aylward
> 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.)
--
The only freedom which deserves the name, is that of pursuing our own
good in our own way, so long as we do not attempt to deprive others of
theirs, or impede their efforts to obtain it.
--John Stuart Mill (On Liberty, 1859)
Brian Hogan
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.
voodoorai2000
>
> 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
> 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:http://norvig.com/Gettysburg/
>
> 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.)
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 '/'.
>
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 :)
> 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 :) 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 :) So, your
> > application will become easier to spec and thus to maintain and extend
> > with confidence.
>
> You're arguing in a circle.
>
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
>
> I'm sorry: are you saying you need REST to output (or input) XML?
> I don't think that's the case.
>
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.
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 :)
tonypm
I can see sense in this 'RESTFUL' concept, adding the convention to
url routing,methods and controllers, is, as I see it, a meaningful
extension to the whole framework concept.
Saying 'I dont use or need web services' is not really an argument. I
dont either, but I might in the future, so the argument that says
adding web services later comes virtually for free is valid
futureproofing.
Having said that, I do relate to the original point being made. I
think some of the issue comes down to terminology and definition and
guidance. If you already have a grasp of this stuff and you are doing
web services then it probably makes sense. But to me, the term REST
is not tangible and borders on meaningless. As I understand it, REST
was itself really just a concept of stateless web page transactions.
Please correct me if I'm wrong. I cannot get this stuff concrete in
my mind and would love to see some rather more meaningful terminology
used that would make it clearer what is being referred to.
In one of my apps, I had to rework my Customer interface/controller
because I wanted to access the customer edit/add/lookup from within
another context using redbox popups. I decided to use REST resource
and I think I succeeded. Using the b-simple Restful rails pdf and
listening to ?DHH's presentation several times, I was able to use the
path parameters in most of my links and forms. But I am still not
sure if I did CRUD or REST or what. I used the scaffold framework,
and then removed the responds to stuff cos I didnt need it. But my
structure now allows me to put it back in the future if necessary.
CRUD to me is something specific. But just what are 'restful
resources'. I would really like to see the concepts grounded in a
more concrete way. Isnt a restful resource actually a CRUD
resource?? I can already hear you say - well no it isnt quite! Then
exactly what is it? In my understanding, I could make a restful web
service and not use the CRUD operations. But that would clearly not
be what Rails is meaning by restful resource. In some way it is
relating to the verb/noun url paradigm. But what has that got to do
with REST. I hope you can see my confusion here. I reckon that there
are several concepts lurking under the term rest which are implicitly
understood, but not explicitly tangible to those like me who have not
yet managed to fully enter in with their thought processes.
In summary then - I think I like it, I want to use it, but I can't
quite grasp it.
Tonypm
voodoorai2000
> quite grasp it.
> Tonypm
least I think I understand it :)
The following is copy and paste from Wikipedia (http://
en.wikipedia.org/wiki/REST) I just put it here for convenience.
Representational State Transfer (REST) is a style of software
architecture for distributed hypermedia systems such as the World Wide
Web. The terms "Representational State Transfer" and "REST" were
introduced in 2000 in the doctoral dissertation of Roy Fielding,[1]
one of the principal authors of the Hypertext Transfer Protocol (HTTP)
specification. The terms have since come into widespread use in the
networking community.
REST strictly refers to a collection of network architecture
principles that outline how resources are defined and addressed. The
term is often used in a looser sense to describe any simple interface
that transmits domain‐specific data over HTTP without an additional
messaging layer such as SOAP or session tracking via HTTP cookies.
These two meanings can conflict as well as overlap. It is possible to
design any large software system in accordance with Fielding's REST
architectural style without using HTTP and without interacting with
the World Wide Web. It is also possible to design simple XML+HTTP
interfaces that do not conform to REST principles, and instead follow
a model of remote procedure call. The difference between the uses of
the term "REST" causes some confusion in technical discussions.
Systems that follow Fielding's REST principles are often referred to
as "RESTful".
Principles
REST's proponents argue that the Web enjoyed the scalability and
growth that it has had as a direct result of a few key design
principles:
Application state and functionality are divided into resources
Every resource is uniquely addressable using a universal syntax for
use in hypermedia links
All resources share a uniform interface for the transfer of state
between client and resource, consisting of
A constrained set of well-defined operations
A constrained set of content types, optionally supporting code on
demand
A protocol that is:
Client-server
Stateless
Cacheable
Layered
REST's client‐server separation of concerns simplifies component
implementation, reduces the complexity of connector semantics,
improves the effectiveness of performance tuning, and increases the
scalability of pure server components. Layered system constraints
allow intermediaries--proxies, gateways, and firewalls--to be introduced
at various points in the communication without changing the interfaces
between components, thus allowing them to assist in communication
translation or improve performance via large‐scale, shared caching.
REST enables intermediate processing by constraining messages to be
self‐descriptive: interaction is stateless between requests, standard
methods and media types are used to indicate semantics and exchange
information, and responses explicitly indicate cacheability.
@Anton
Claimed benefits
Many of the statements below refer to REST in the specific context of
Web Services, as opposed to SOAP. REST was originally defined in
Fielding's dissertation in the context of information and media
access. Fielding did not originally contrast REST with RPC.
Advocates claim that REST:
Provides improved response times and server loading characteristics
due to support for caching
Improves server scalability by reducing the need to maintain
communication state. This means that different servers can be used to
handle initial and subsequent requests
Requires less client‐side software to be written than other
approaches, because a single browser can access any application and
any resource
Depends less on vendor software than mechanisms that layer additional
messaging frameworks on top of HTTP
Provides equivalent functionality when compared to alternative
approaches to communication
Does not require a separate resource discovery mechanism, due to the
use of hyperlinks in content
Provides better long‐term compatibility and evolvability
characteristics than RPC. This is due to:
The capability of document types such as HTML to evolve without
breaking backwards‐ or forwards‐ compatibility, and
The ability of resources to add support for new content types as they
are defined without dropping or reducing support for older content
types.
REST detractors note the lack of tool support and the scarcity of
truly RESTful applications deployed on the web of today. Some claim
that REST is applicable to GET, but unproven for other state transfer
operations such as PUT. Fielding points out in his thesis that the
REST architecture was designed specifically for massive scale
hypermedia distribution, and not as a one size fits all architectural
style. Indeed what characterizes REST is the constraints that it
imposes on a REST based system. POST is often considered the only
necessary client‐to‐server state transfer operation, and is treated as
a mechanism to tunnel arbitrary method invocations across HTTP.
Some REST systems have been deployed and gained tools support such as
WebDAV which uses not only GET and POST, but also established HTTP
methods like HEAD, DELETE, PUT as well as WebDAV‐specific HTTP
methods: PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, and UNLOCK.
One common stumbling block in the dialog on Claimed Benefits is
focusing too much on web browser support for REST. Gateways, caching
servers, proxies, and other REST connectors are the critical
components for system design and REST.
[edit]RESTful example: the World Wide Web
The World Wide Web is the key example of a RESTful design. Much of it
conforms to the REST principles. The Web consists of the Hypertext
Transfer Protocol (HTTP), content types including the Hypertext Markup
Language (HTML), and other Internet technologies such as the Domain
Name System (DNS).
HTML can include JavaScript and applets to support code on demand, and
has implicit support for hyperlinks.
HTTP has a uniform interface for accessing resources, which consists
of URIs, methods, status codes, headers, and content distinguished by
MIME type.
The most important HTTP methods are POST, GET, PUT and DELETE. These
are often compared with the CREATE, READ, UPDATE, DELETE (CRUD)
operations associated with database technologies:[2]
The following table associates several common HTTP verbs with similar
database operations, however the meaning of the HTTP verbs do not
correspond directly with a single database operation. For example, an
HTTP PUT is used to set the value of a resource and may result in
either a creation or update as needed.
HTTP CRUD
POST Create, Update, Delete
GET Read
PUT Create, Update
DELETE Delete
HTTP separates the notions of a web server and a web browser. This
allows the implementation of each to vary from the other based on the
client‐server principle. When used RESTfully, HTTP is stateless. Each
message contains all the information necessary to understand the
request when combined with state at the resource. As a result, neither
the client nor the server needs to remember any communication state
between messages. Any state retained by the server must be modeled as
a resource.
The statelessness constraint can be violated in HTTP using cookies to
maintain sessions. Fielding notes the risks of privacy leaks and
security complications that often arise through the use of cookies,
and the confusions and bugs that can result from interactions between
cookies and the "back" button in a browser.
HTTP provides mechanisms to control caching, and permits a
conversation between web browser and web cache to occur using the same
mechanisms as between web browser and web server. No layer can access
any conversation other than the one it is immediately involved with.
Anton J Aylward
> CRUD to me is something specific.
For me too.
> But just what are 'restful resources'.
Good question. I find the concept of a 'resource' a bit fuzzy.
> I would really like to see the concepts grounded in a
> more concrete way.
Me too.
> Isnt a restful resource actually a CRUD resource??
Some peole here are saying everything reduces to CRUD.
> I can already hear you say - well no it isnt quite!
Who? Me?
> Then
> exactly what is it? In my understanding, I could make a restful web
> service and not use the CRUD operations.
Not difficult.
> But that would clearly not
> be what Rails is meaning by restful resource. In some way it is
> relating to the verb/noun url paradigm.
Ah. Look at my above responses. I've made them deliberately short, but
they do illustrate that you don't need 'verb/noun' sentences to be
intelligable. Its not that difficult to construct longer sentences
without either verbs or without nouns. Without both takes a bit more
effort.
> But what has that got to do with REST.
Indeed.
> I hope you can see my confusion here.
Yes.
> I reckon that there
> are several concepts lurking under the term rest which are implicitly
> understood, but not explicitly tangible to those like me who have not
> yet managed to fully enter in with their thought processes.
Me too.
>
> In summary then - I think I like it, I want to use it, but I can't
> quite grasp it.
Me too.
> Tonypm
>
--
In view of the stupidity of the majority of the people, a widely held
opinion is more likely to be foolish than sensible.
--Bertrand Russell, Marriage and Morals
Michael D. Ivey
> Good question. I find the concept of a 'resource' a bit fuzzy.
And this is key. Until you really get what a Resource is, REST in
Rails is just a naming convention.
A Resource is any thing in your application that has at least one
name (URL) that uniquely identifies it.
The fundamental change in RESTful thinking is to think in terms of
these things with names, and about the things they can do for us when
we ask them to.
> Some peole here are saying everything reduces to CRUD.
When DHH brought REST to Rails, he got hooked on the REST == CRUD
metaphor. Sometimes (often) that works, but sometimes it doesn't.
So it's more than just CRUD, but that's a good place to start.
Anton J Aylward
> On Jan 7, 2008, at 7:20 AM, Anton J Aylward wrote:
>> Good question. I find the concept of a 'resource' a bit fuzzy.
>
> And this is key. Until you really get what a Resource is, REST in
> Rails is just a naming convention.
>
> A Resource is any thing in your application that has at least one
> name (URL) that uniquely identifies it.
>
> The fundamental change in RESTful thinking is to think in terms of
> these things with names, and about the things they can do for us when
> we ask them to.
??
Isn't that what we've bee doing for the last 40 years that I've been
programming? It was certainly the way I was taught. Do they teach
differently these days?
>> Some peole here are saying everything reduces to CRUD.
>
> When DHH brought REST to Rails, he got hooked on the REST == CRUD
> metaphor. Sometimes (often) that works, but sometimes it doesn't.
Thank you. I suspect admitting that takes some courage :-)
--
For ages, a deadly conflict has been waged between a few brave men and
women of thought and genius upon the one side, and the great ignorant
religious mass on the other. This is the war between Science and Faith.
The few have appealed to reason, to honor, to law, to freedom, to the
known, and to happiness here in this world. The many have appealed to
prejudice, to fear, to miracle, to slavery, to the unknown, and to
misery hereafter. The few have said "Think" The many have said "Believe!"
--Robert Ingersoll (Gods)
Michael D. Ivey
>> When DHH brought REST to Rails, he got hooked on the REST == CRUD
>> metaphor. Sometimes (often) that works, but sometimes it doesn't.
>
> Thank you. I suspect admitting that takes some courage :-)
Not at all.
REST predates Rails, and REST is more than CRUD. The Rails
implementation of super-easy REST is very CRUD oriented, and it's a
decent metaphor. It's not an absolute, though.
I didn't say REST didn't apply everywhere. I maintain that by
definition, every web application can be modeled in terms of resources.
Just that it's not necessarily CRUD.
Peter Dierx
I was rewatching the Railsconf 2006 keynote from David and its all about
REST.
He talks about the implementation of REST in combination with has_many
:through.
I think its a very good talk if you want to know more about REST.
Even without the slides you can follow a long quite well.
It gives a clear insight on how he was thinking at the time.
Its up for grabs here.
http://blog.scribestudio.com/pages/rails/
You want the David Heinemeier Hansson download.
And do yourself a favor and watch Martin Fowler.
Now don't go hammer the server all at once :-)
Regards.
Peter Dierx
http://www.railstation.eu/blog
PS
I will post this in 'REST Style' and 'WHY Rest'
Ryan Bigg
--
Ryan Bigg
http://www.frozenplague.net
Feel free to add me to MSN and/or GTalk as this email.
J2M
On Jan 4, 3:03 pm, Anton J Aylward <a...@si.on.ca> wrote:
> I've plugged "restful authentication" into my wiki and that's fine
> because its compartmentalized, but the rest of the wiki works entirely
> on urls of the form
...
> The authentication function is completely orthogonal to the Wiki space
> so having '/login' and '/register' is not an issue.
>
> You say "RESTful web design is cleaner and much easier to understand"
> but I don't see that. So many people say that and its getting to sound
> like a "fashion" and "proof by assertion". As I've said, there are blog
> postings where people claim this simplification by don't show the 'how'
> and don't show it in a way that I can learn from the process.
I think the change from acts as authenticated to restful
authentication is a very clear example. Where the controller used to
have the #login and #logout methods in it, restful authentication
moved them into a new restful session controller. This seems at first
glance just like an extra file that isn't really needed, but the major
change is the semantics, I think technoweenie asked himself "With
these extra methods what is the entity I am dealing with?" in asking
that question you get the answer "A session".
That semantic shift to me is the thing that makes you think
differently about design. Now -in restful authentication- there is a
controller that allows you to create, read, update and delete accounts
which maps directly to the model and likewise you have a contrller
that allows you to create and delete a session. There is a clear
separation of concerns there which makes it easier to think about the
structure and behaviour of your application.
I know this is a very simplified example, but the thought process that
lead to the simplification of that plugin shows how to question the
complexity of your controllers. Prior to this change there was a lot
of debate about authentication being one of those examples where
restful controllers wouldn't work.
James