Should I care to design my application in RestFull manner if donot 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
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)
Ryan Bigg said the following on 04/01/08 04:25 AM:
Is it enough to not type something as horrible as:
link_to @topic.name <http://topic.name>, { :controller => "topics", :action => "view", :id => @topic.id <http://topic.id> }
when Restful Routing gives you:
link_to @topic.name <http://topic.name>, topic_path(@topic)
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".
Ryan Bigg said the following on 04/01/08 04:25 AM:
Is it enough to not type something as horrible as:
link_to @topic.name <http://topic.name>, { :controller => “topics”, :action => “view”, :id => @topic.id <http://topic.id> }
when Restful Routing gives you:
link_to @topic.name <http://topic.name>, topic_path(@topic)
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
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
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.
Amos King said the following on 04/01/08 09:31 AM:
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'.
Jason Roelofs said the following on 04/01/08 07:33 AM:
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?"
Amos King said the following on 04/01/08 09:31 AM:
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.
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).
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
Jeremy McAnally said the following on 04/01/08 10:44 AM:
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?
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.
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
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
I don't "get" REST, either. Web service for free? Great - if you need 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
I don't see what extra work you were having to do; I can write a 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
The work would be to convert a working application to REST. I really 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
Mark Wilden said the following on 04/01/08 01:18 PM:
I don't "get" REST, either. Web service for free? Great - if you need 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.
Thank you so much, Mark. You've expressed a few points that I've omitted.
Jeremy McAnally said the following on 04/01/08 12:01 PM:
It's just an easier, cleaner way to structure your application.
OK, but HOW?
Jeremy McAnally said the following on 04/01/08 12:01 PM:
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
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.
Michael D. Ivey said the following on 04/01/08 11:58 AM:
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?
No but you get a bunch of them generated for free.
Why _not_ use them?
--Jeremy