REST and multiple resources in a view??

rubyonrails-talk
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    6.    7. class Location < ActiveRecord::Base    8. belongs_to :Restaurant    9. end   10.   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 --

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

  3. belongs_to :Location   4. ...   5. end   6.   7. class Location < ActiveRecord::Base   8. belongs_to :Restaurant   9. end 10. 11. class Restaurant < ActiveRecord::Base 12. has_many :Location

Lowercase and plural :slight_smile:

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?

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

4

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

5

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

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 softiesonrails.com purpleworkshops.com

6

Hi --

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.

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 Angeles"), 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.

7

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