4 ms·

I think they should get rid of controllers and instead model RESTful / resource-oriented concepts like Resource and Entity directly! A Resource is an object wh

by mjw 16y ago

I think they should get rid of controllers and instead model RESTful / resource-oriented concepts like Resource and Entity directly! A Resource is an object which responds to some subset of GET, PUT, POST and DELETE. It has a unique URL which identifies it. (OK it's a bit more complicated than that, but you get the gist). At present Controllers in Rails are a flat grab-bag of procedural code loosely associated with some group of resources, with meta-programming used to sweep some of the mess under the carpet. They're not an elegant way to model RESTful concepts. (I actually have a framework in development for doing resource-oriented APIs on top of Rack, however it's currently very pre-1.0)

mjw 16y ago
One particular thing which bothers me about controllers is the way they lump together obviously class- or collection-level methods (index, create, ...) with instance-level methods (show, update, delete, ...). IMO requests should be routed to an instance representing a particular resource; the methods on that resource should correspond directly to the HTTP request methods. The collection (or the class) is a separate resource.
- dkubb 16y ago
  Agreed. I always thought that Rails controllers violated the Single Responsibility Principle (http://en.wikipedia.org/wiki/Single_responsibility_principle http://en.wikipedia.org/wiki/Single_responsibility_principle) by mixing collection and member concerns into a single class.
cloudhead 16y ago
This is really interesting, care to share more info?
- mjw 16y ago
  Sorry just noticed this, here's the link to the project: http://github.com/mjwillson/doze http://github.com/mjwillson/doze Warning: rough edges, etc :)
psadauskas 16y ago
I've been thinking about this very thing for awhile, too. I wrote some code to demonstrate how I think resource/routes/controllers should work: https://gist.github.com/d64847016687e82d104b https://gist.github.com/d64847016687e82d104b Started on an implementation based on Rails 3 ActionPack, but never got very far. To make the case statements work, you have to override #=== on Symbol.
bscofield 16y ago
I was working on a framework like this, too -- I spoke about it at RubyConf in 2008, and the last version of the code (from 2009) is at http://github.com/bscofield/athena http://github.com/bscofield/athena I put it on hold a while back, though I'm thinking about bringing it back on top of Rails 3's more flexible substructure.
xmlblog 16y ago
Sounds like an interesting idea, but raises a few questions. What are the responsibilities of a resource? What actions does it know how to perform? You mentioned responding to the HTTP verbs, so clearly it knows about HTTP. Does it know how to interact with a persistence layer? If so, I think it's seriously overburdened. If not, and this perhaps is what your Entity is responsible for, then you can have an Account resource and an Account entity. Or, in other words, an Account controller, and an Account model, essentially changing little but class and method names. Another thing that bothers me is that (assuming Resource + Entity) a resource is supposed to "be" that abstract thing you're viewing / manipulating in a RESTful architecture. But this nomenclature demotes it to a proxy to that concept. I suppose one could criticize Rails similarly, except that Rails intentionally keeps the notion of a resource abstract.
- mjw 16y ago
  Good questions. > What are the responsibilities of a resource? What actions does it know how to perform? You mentioned responding to the HTTP verbs, so clearly it knows about HTTP. Yep, it's entirely a HTTP-level concept. It is aiming to model exactly the concept of a resource which is referred to in the relevant RFCs > Does it know how to interact with a persistence layer? If so, I think it's seriously overburdened. Nope, and I agree. (Although it is available as mixins, so you could mix it into your model classes if you wish. However I'm tending towards discouraging this) > If not, and this perhaps is what your Entity is responsible for Nope - at present an entity is, as per the RESTful jargon, quite a simple object which represents an instance of some media type. You can declare a lazy entity with a block though, to avoid generating the response bytes for an entity which was refused by content negotiation. > Another thing that bothers me is that (assuming Resource + Entity) a resource is supposed to "be" that abstract thing you're viewing / manipulating in a RESTful architecture. But this nomenclature demotes it to a proxy to that concept. I suppose one could criticize Rails similarly, except that Rails intentionally keeps the notion of a resource abstract. Think I sort of get what you mean here, but that it's not really as much of a concern when you think about it. Really my goal first and foremost is to formalise the interfaces which one ought to expose in order for an object to be served up as a resource by a restful HTTP server. So in that sense, the framework is to be considered more a plugin API for RESTful HTTP servers, along the lines of Restlet for Java There is inevitably still some boilerplate in wrapping persistence layer objects in such interfaces, but the plan is to develop standard wrappers for ActiveModel classes and instances to help with that. And of course, not every resource is backed by an ORM. I've found the process of trying to pin down the right interface for a Resource quite interesting though, in that it's lead me to read the HTTP RFCs a lot deeper than I otherwise would have. There's still some way to go, though.

by mjw 16y ago

mjw 16y ago

One particular thing which bothers me about controllers is the way they lump together obviously class- or collection-level methods (index, create, ...) with instance-level methods (show, update, delete, ...). IMO requests should be routed to an instance representing a particular resource; the methods on that resource should correspond directly to the HTTP request methods. The collection (or the class) is a separate resource.

dkubb 16y ago
Agreed. I always thought that Rails controllers violated the Single Responsibility Principle (http://en.wikipedia.org/wiki/Single_responsibility_principle http://en.wikipedia.org/wiki/Single_responsibility_principle) by mixing collection and member concerns into a single class.

cloudhead 16y ago

This is really interesting, care to share more info?

mjw 16y ago
Sorry just noticed this, here's the link to the project: http://github.com/mjwillson/doze http://github.com/mjwillson/doze Warning: rough edges, etc :)

psadauskas 16y ago

I've been thinking about this very thing for awhile, too. I wrote some code to demonstrate how I think resource/routes/controllers should work: https://gist.github.com/d64847016687e82d104b https://gist.github.com/d64847016687e82d104b Started on an implementation based on Rails 3 ActionPack, but never got very far. To make the case statements work, you have to override #=== on Symbol.

bscofield 16y ago

I was working on a framework like this, too -- I spoke about it at RubyConf in 2008, and the last version of the code (from 2009) is at http://github.com/bscofield/athena http://github.com/bscofield/athena I put it on hold a while back, though I'm thinking about bringing it back on top of Rails 3's more flexible substructure.

xmlblog 16y ago

Sounds like an interesting idea, but raises a few questions. What are the responsibilities of a resource? What actions does it know how to perform? You mentioned responding to the HTTP verbs, so clearly it knows about HTTP. Does it know how to interact with a persistence layer? If so, I think it's seriously overburdened. If not, and this perhaps is what your Entity is responsible for, then you can have an Account resource and an Account entity. Or, in other words, an Account controller, and an Account model, essentially changing little but class and method names. Another thing that bothers me is that (assuming Resource + Entity) a resource is supposed to "be" that abstract thing you're viewing / manipulating in a RESTful architecture. But this nomenclature demotes it to a proxy to that concept. I suppose one could criticize Rails similarly, except that Rails intentionally keeps the notion of a resource abstract.

mjw 16y ago
Good questions. > What are the responsibilities of a resource? What actions does it know how to perform? You mentioned responding to the HTTP verbs, so clearly it knows about HTTP. Yep, it's entirely a HTTP-level concept. It is aiming to model exactly the concept of a resource which is referred to in the relevant RFCs > Does it know how to interact with a persistence layer? If so, I think it's seriously overburdened. Nope, and I agree. (Although it is available as mixins, so you could mix it into your model classes if you wish. However I'm tending towards discouraging this) > If not, and this perhaps is what your Entity is responsible for Nope - at present an entity is, as per the RESTful jargon, quite a simple object which represents an instance of some media type. You can declare a lazy entity with a block though, to avoid generating the response bytes for an entity which was refused by content negotiation. > Another thing that bothers me is that (assuming Resource + Entity) a resource is supposed to "be" that abstract thing you're viewing / manipulating in a RESTful architecture. But this nomenclature demotes it to a proxy to that concept. I suppose one could criticize Rails similarly, except that Rails intentionally keeps the notion of a resource abstract. Think I sort of get what you mean here, but that it's not really as much of a concern when you think about it. Really my goal first and foremost is to formalise the interfaces which one ought to expose in order for an object to be served up as a resource by a restful HTTP server. So in that sense, the framework is to be considered more a plugin API for RESTful HTTP servers, along the lines of Restlet for Java There is inevitably still some boilerplate in wrapping persistence layer objects in such interfaces, but the plan is to develop standard wrappers for ActiveModel classes and instances to help with that. And of course, not every resource is backed by an ORM. I've found the process of trying to pin down the right interface for a Resource quite interesting though, in that it's lead me to read the HTTP RFCs a lot deeper than I otherwise would have. There's still some way to go, though.