WHY Rest

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

   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

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. :slight_smile:

///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. :slight_smile:

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

   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.

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