REST and multiple resources in a view?

Rails
1

hello all,
I’m trying to get my feet wet with a small webapp but it’s getting
frustrating to put together all the pieces of the REST/CRUD/restful
controllers/composite views (composite meaning with more than 1
resources in the view).
So to make the problem concrete I have the following models

  1. class Deal < ActiveRecord::Base
  2. belongs_to :Restaurant
  3. belongs_to :Location
  4. …
  5. end
  7. class Location < ActiveRecord::Base
  8. belongs_to :Restaurant
  9. end
  11. class Restaurant < ActiveRecord::Base
  12. has_many :Location
  13. has_many :Deal
  14. …
  15. end

In my mind each of these models corresponds to a resource, so each
model come with its controller and its 7 CRUD controller actions, and
the route mappings in routes.rb.

Up till now restful design is adhered (I think). What buffles me is
how to present information from these 3 models (or any number of
models, for that matter) in a single (composite) view and still remain
RESTful? Use of partials and a dedicated controller with 1 action
(without an underlying model) in order to present these resources in a
single view doesn’t seem very restful to me. Regardless of REST, is
the above solution (partials and dedicated controller) a valid RoR
approach?

I read somewhere that REST makes more sense in a web services scenario
than a UI webapp. How much of this is true?

Regarding the resource generator: it scaffolds a model and an empty
controller. Does this make any sense when the Rails take on REST tends
to associate a resource with an ActiveRecord model, or a model/
controller stack? I mean, where are the CRUD actions? The scaffold
generator scaffolds a restful controller and the views, which I do not
want since I need composite screens.

sigh and thank you

2

Any takes on this please?

3

Hi –

On Wed, 6 Aug 2008, billis wrote:

hello all,
I’m trying to get my feet wet with a small webapp but it’s getting
frustrating to put together all the pieces of the REST/CRUD/restful
controllers/composite views (composite meaning with more than 1
resources in the view).
So to make the problem concrete I have the following models

  1. class Deal < ActiveRecord::Base
  2. belongs_to :Restaurant

You want the lowercase there: :restaurant

  1. belongs_to :Location
  2. …
  3. end
  5. class Location < ActiveRecord::Base
  6. belongs_to :Restaurant
  7. end
  9. class Restaurant < ActiveRecord::Base
  10. has_many :Location

Lowercase and plural :slight_smile:

models, for that matter) in a single (composite) view and still remain
RESTful? Use of partials and a dedicated controller with 1 action
(without an underlying model) in order to present these resources in a
single view doesn’t seem very restful to me. Regardless of REST, is
the above solution (partials and dedicated controller) a valid RoR
approach?

RESTfulness per se varies independently of how much data you show in a
given view, and where the data comes from. Also, you can characterize
your resource in any way you like (“deals at restaurant X at location
Y”). Then you can map it to Rails’s facilities in what you find is
the best way.

I read somewhere that REST makes more sense in a web services scenario
than a UI webapp. How much of this is true?

I wouldn’t say that unconditionally. There’s more to say but it’s kind
of a different topic.

Regarding the resource generator: it scaffolds a model and an empty
controller. Does this make any sense when the Rails take on REST tends
to associate a resource with an ActiveRecord model, or a model/
controller stack? I mean, where are the CRUD actions? The scaffold
generator scaffolds a restful controller and the views, which I do not
want since I need composite screens.

I would (and do) stay away from the scaffolding. It does, as you say,
have a very specific, generic way of manifesting the concept of a
“resource” (model/controller stack), and any application that does
anything non-generic (i.e., pretty much every application) will
require that you do your own.

I would start by trying to describe the resource you wish to represent
in English, and then start to consider how much of the work you can
get Rails to do and how much you have to do yourself. Also, have a
look at:

http://dablog.rubypal.com/2008/3/23/splitting-hairs-over-resource
http://dablog.rubypal.com/2008/4/24/splitting-hairs-over-resource-part-2

David

–
Rails training from David A. Black and Ruby Power and Light:

  • Advancing With Rails August 18-21 Edison, NJ
  • Co-taught by D.A. Black and Erik Kastner
    See http://www.rubypal.com for details and updates!
4

On Wed, 6 Aug 2008, billis wrote:

hello all,
I’m trying to get my feet wet with a small webapp but it’s getting
frustrating to put together all the pieces of the REST/CRUD/restful
controllers/composite views (composite meaning with more than 1
resources in the view).

I’ve been on vacation but would like to add that I hear this question
quite a bit. I think having a “home page” or “multi-resource” view is
perfectly RESTful if you are able to think of that composite view as a
representation of a resource unto itself.

I used to work at a retail store. The front window contained a
variety things, in order to attract customers into the store. Once
inside the store, products were typically separated into their
respective aisles.

I guess it’s a bit of a gray area, but to me, it’s perfectly valid to
have a “front window” resource, and use a representation of it as your
“home page” or whatever. I tend to prefer the index action of a
HomePageController, but some people think the show action makes more
sense. But it usually boils down to rendering some partials at some
point, and I think that’s fine.

On Aug 8, 12:53 pm, “David A. Black” [email protected] wrote:

I would start by trying to describe the resource you wish to represent
in English, and then start to consider how much of the work you can
get Rails to do and how much you have to do yourself. Also, have a
look at:

http://dablog.rubypal.com/2008/3/23/splitting-hairs-over-resource
http://dablog.rubypal.com/2008/4/24/splitting-hairs-over-resource-part-2

David

David’s articles are excellent, especially when he explains the
difference between a resource and its representation. It’s a
distinction that’s not made often enough in tutorials about REST.

–
Rails training from David A. Black and Ruby Power and Light:

  • Advancing With Rails August 18-21 Edison, NJ
  • Co-taught by D.A. Black and Erik Kastner

And if you can’t get to David’s class, consider our workshop on REST
coming up:
http://www.purpleworkshops.com/workshops/rest-and-web-services

Jeff

purpleworkshops.com

5

Hi –

On Sun, 10 Aug 2008, Jeff wrote:

I’ve been on vacation but would like to add that I hear this question
quite a bit. I think having a “home page” or “multi-resource” view is
perfectly RESTful if you are able to think of that composite view as a
representation of a resource unto itself.

Definitely. Fielding puts it like this: “Any information that can be
named can be a resource: a document or image, a temporal service (e.g.
“today’s weather in Los A.”), a collection of other resources, a
non-virtual object (e.g. a person), and so on.” [1]

David

[1]
http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_2_1_1
Fielding, Roy Thomas. Architectural Styles and the Design of
Network-based Software Architectures. Doctoral dissertation,
University of California, Irvine, 2000.

–
Rails training from David A. Black and Ruby Power and Light:

  • Advancing With Rails August 18-21 Edison, NJ
  • Co-taught by D.A. Black and Erik Kastner
    See http://www.rubypal.com for details and updates!
6

I guess it’s a bit of a gray area, but to me, it’s perfectly valid to
have a “front window” resource, and use a representation of it as your
“home page” or whatever.

That’s how Im organising my controllers/views in regards to resources,
after reading David’s articles on REST, and I have to say it’s very
“liberating” to put resources in this perspective. I’m very new to
Rails but I feel that, after reading a couple of books on RoR, the
“official Rails” REST approach of most of the existing Rails
documentation present REST in a very RoR-centric way. The result is,
at least in my case, to be confused on how REST is used in RoR and how
to apply the REST concepts in Rails development ( I haven’t read
Fielding’s text but I’ll definitely will ).

Again, very ilumintaing articles, perhaps some sort of guide/text is
needed on REST *for RoR development".
vassilis

7

exactly what I needed to get a better perspective on REST. thanks