RESTful design

Rails
1

I have difficulties to get into restful thinking, so sorry for a
possibly stupid question.

How do you deal with a product listing which has one interface for admin
and another for customers? It needs more methods than the ones in rest,
right?

There must be plenty of similar situations which makes restful design
less logical.

2

No, it doesn’t necessarily need more actions.

Changing the product’s price? that’s an update
Changing its on-hand quantity? That’s an update
Changing it’s availability? That’s an update.

You may opt to have two controllers for your products… one for the
public
pages where the products are displayed and then a different one for
product
managemet, or you may instead opt to show different views to your
customers
vs your admins.

You also don’t have to follow the Rails REST pattern if you don’t want
to,
but it does make things easier once you get the hang of it. It’s
important
to remember that while the default Rails REST scaffolding maps a model
to a
controller,

  • A “resource” can be a controller that exists without a model
    (Sessions)
  • You can have several resources pointing to one model
    (AvailableProducts,
    SaleItems)
  • A model doesn’t have to be backed by a database
  • You are allowed to tack on additional methods
    map.resources :producs, :member => {:approve => :put, :reject =>
    :put},
    :collection =>{:available => :get}

Hope that helps some.

2009/10/1 PÃ¥l Bergström [email protected]

3

Brian H. wrote:

Hope that helps some.

It does. Thanks :slight_smile:

4

Pål Bergström wrote:

I have difficulties to get into restful thinking, so sorry for a
possibly stupid question.

How do you deal with a product listing which has one interface for admin
and another for customers? It needs more methods than the ones in rest,
right?

There must be plenty of similar situations which makes restful design
less logical.

I replied to a very similar question a day or two ago.

Rails provides namespaced resources for just this sort of need.

See the following reply:
http://www.ruby-forum.com/topic/196355#new

5

Robert W. wrote:

I replied to a very similar question a day or two ago.

Rails provides namespaced resources for just this sort of need.

See the following reply:
2 RESTful controllers for the same resource - Rails - Ruby-Forum

Thank you. However I still not sure I see the benefit from the old way.
Especially when you have a lot of extra logic and presentations/views. I
mean work-wise it must mean equally much work.

Are there any professional rails programmers that doesn’t work with
RESTful design, and if so why?

6

Pål Bergström wrote:

Robert W. wrote:

I replied to a very similar question a day or two ago.

Rails provides namespaced resources for just this sort of need.

See the following reply:
2 RESTful controllers for the same resource - Rails - Ruby-Forum

Thank you. However I still not sure I see the benefit from the old way.
Especially when you have a lot of extra logic and presentations/views. I
mean work-wise it must mean equally much work.

I don’t view the RESTful design as an effort to reduce the amount of
work. It’s not about that at all in my view. Compare it to the benefit
of testing. I think everyone would agree that doing TDD/BDD add more
work up front. It certainly add more lines of code the develop has to
write. What we hope for from testing is that it will make life easier
later and raise our confidence in the code we write.

The benefit is similar with RESTful Rails (at least as I see it). Before
the new RESTful style everyone was just doing their own thing by
defining routes to arbitrary actions with little consistency. The new
way imposes new conventions removing even more decisions about how to
architect an application.

Eliminating decisions sounds like a bad thing to a lot of people. Maybe
that has some merit when there’s just one developer on a project. But,
when you work in a team (or open source) these types of decisions are
bad. Reducing the number of design decisions leads to more maintainable
code, and a more consistent architecture. More consistent architecture
reduces the effort when looking at other people’s code. You begin to
expect certain things in certain places with specific names. This mean
you don’t have to spend time deciphering what the developer means by
“show,” “new,” “create”, etc. These actions are now defined by
convention.

People often seem to confuse “convention” with “limitation.” I don’t see
that the RESTful design imposes any limitations on your overall design.
It only imposes conventions for the things that all applications need to
perform like listing, creating, changing, showing and destroying things.

So maybe you don’t see the benefits, possibly because you haven’t given
REST a real chance to grab your imagination, or it just doesn’t fit your
development style. I started off struggling with this idea myself so I
put my mind to work studying to understand why it has merit. I now feel
the freedom of not having the think about these basic design decisions,
so I go on with what makes my application unique and interesting.

Are there any professional rails programmers that doesn’t work with
RESTful design, and if so why?

I’m sure there probably are, but I think the number of them are
shrinking as more developers begin to see the benefits of REST. One
thing that I’m pretty sure about is that RESTful design is here to stay.
I believe all future development of the Rails framework will focus on
making that design style better. I imagine pretty much no effort will be
spent on the “old” style. I don’t think it will be removed from Rails
anytime soon, but the RESTful style has been hugely successful and I
think that’s great.

All this being said, if you’re the architect of your own project then do
things however you want. But, if you ever need to work with a team of
Rails developers you might have a battle on your hands.

I also think that the vast majority of feedback you get from this forum
will encourage the RESTful design style.