Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rethinking Rails 3 Controllers and Routes - PeepCode Blog

blog.peepcode.com

Post reply on HN
Print view View original

41–48 of 48 posts

Re: Rethinking Rails 3 Controllers and Routes - PeepCode Blog

#41

Post by sashthebash »

I encountered an even bigger problem/limitation while implementing a RESTful API with Rails. It was that it's not easy to follow one of the most important principles of REST (from Wikipedia):

"An important concept in REST is the existence of resources (sources of specific information), each of which is referenced with a global identifier (e.g., a URI in HTTP)."

I do not find the global identifier (URI) in Rails when I just do a "render :xml => @model" or "render :xml => @array". Instead of a global identifier the id of the object is in the representation of the resource.

What is missing are the links between all the resources. When a client fetches a collection it must guess or reconstruct the URIs manually for the individual members. This makes it impossible to change the route generation on the server without breaking the client.

In REST Rails Models are Resources, but Rails Models don't know anything about their global unique id (URL). I wish there would be a way to just say user.uri and I would get something like "http://myservice.com/users/1 or user.path "/users/1". It would be nice if this would be considered when rewriting the Rails router. Maybe the routes should be defined in the model (=resource) itself?!

I tried to implement links between resources in the API I created. You can find some information in documentation at http://wiki.tagcrumbs.com/developers/rest. In my opinion an XML representation of a truly RESTful service should look something like this: http://wiki.tagcrumbs.com/developers/resources/user#examples. Comments are highly appreciated.

Re: Rethinking Rails 3 Controllers and Routes - PeepCode Blog

#42

Post by elight »

dhh wrote: post #2

What an awesome way to advocate for code change. Very pretty. Unfortunately, I also think it's faulty. First, it doesn't actually advocate anything concrete. There's some hand-waving to Sinatra and other Rails features, but nothing concrete. If you're going to make such a pretty proposal, it should come with a call to specific action that people can get behind. This is double true when it comes to API design. It's al…

"get(:member) do |id|" or "get "/api/v1/report/:id" do |id|" have the virtue of being pretty damn explicit.

As far as ensuring API consistency (a fine goal), it wouldn't be altogether difficult to have a rake task that prints the full set of routes to STDOUT for app's using such a framework. Load all of the controllers, make a route table, then emit said route table. This provides a holistic view of Sinatra-like routes similar to "rake routes".

Just the same, I can see how for apps with many types of resources, remembering the precise URL incantation would PROBABLY be more difficult than remembering Rails generated path/URL helpers.

Re: Rethinking Rails 3 Controllers and Routes - PeepCode Blog

#43

Post by bscofield »

mjw wrote: post #11

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 s…

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

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.

Re: Rethinking Rails 3 Controllers and Routes - PeepCode Blog

#44

Post by xmlblog »

mjw wrote: post #11

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 s…

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.

Re: Rethinking Rails 3 Controllers and Routes - PeepCode Blog

#45

Post by mjw »

cloudhead wrote: post #20
mjw wrote: post #11

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 s…

This is really interesting, care to share more info?

Sorry just noticed this, here's the link to the project: http://github.com/mjwillson/doze

Warning: rough edges, etc :)

Re: Rethinking Rails 3 Controllers and Routes - PeepCode Blog

#46

Post by mjw »

xmlblog wrote: post #44
mjw wrote: post #11

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 s…

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 res…

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.

Re: Rethinking Rails 3 Controllers and Routes - PeepCode Blog

#47

Post by mjw »

mjw wrote: post #46
xmlblog wrote: post #44

Earlier quoted context omitted.

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 res…

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

One other big thing to point out is that this approach has the biggest pay-off when you're doing API-focused development (eg writing RESTful web services for thick client applications to use, which was where the framework originated from).

While you could do more traditional web apps this way too, I haven't really tried to optimise for that use case at present. It would need more rails-style glue code and help for HTML templating etc to get there, although that's certainly doable.

I've also been waiting to see if the new more flexible Rails makes it possible to switch in the resource-based routing and controller approach that I want. Sadly I suspect there wouldn't be much of Rails left by that point (we're not using ActiveRecord either), but bears investigation.

Re: Rethinking Rails 3 Controllers and Routes - PeepCode Blog

#48

Post by mikek85 »

dkubb wrote: post #38
_pius wrote: post #28

Earlier quoted context omitted.

The over-engineer in me likes the way Rails 3 does it. That way I can pretend that my code is reusable, as the URL is decoupled from the code that eventually implements its handler. You don't have to pretend ... it actually is reusable. I don't get what's "over-engineer"ed about it.

Whenever I've tried to reuse the same controller for two URLs, I usually end up with some conditional logic within the controller to handle difference in parameters available from the URL. I think a better approach would've been for me to subclass one from the other, or have a common parent class, and then handle the parameter differences within each subclass. At that point you'd end up with a 1:1 mapping between con…

That 1:1 mapping is a good thing, but I don't think that's a reason to completely do-away with routing altogether. Sticking the route in the controller just makes the code harder to follow.
Post reply on HN