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)
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.
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.
> 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.
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.
Warning: rough edges, etc :)
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 all fine and good to general ideas and principles guiding you, but when the code hits the editor is when all the constraints and trade-offs are revealed. I could fill a book with all the premature ideas I had for API rewrites that turned out not work when applied to the tough reality of real code.
But I'm wearing too far into hand-waving territory too, so let me address a few of the points raised:
1) "Not specifying URLs directly leads to poor [URL] API design and other ills": There are only so many (reasonable) ways to specify a URL if you want to follow REST principles. You name your resource and you give it an identifier.
/products/1-some-perma-id became a pattern because it was both simple, repeatable across models, and extractable. Why spend time coming up with a unique URL structure for every model that you want to expose when they follow the same pattern of using the model name as the url identifier?
This is exactly what Rails does and always have done. Spot patterns currently done by hand, extract said pattern into a convention, allow people to move on from thinking about how to do X until they hit an exception. This, in my mind, is exactly what leads to great API design and simple solutions. You do the same as everyone else when the choice is less important than the consistency.
Now I welcome the praise for Sinatra. I think it's completely awesome. I'd use it for smaller projects myself. But that's exactly where conventions don't give you that much. If you're exposing, say, 20 urls to the public, you don't gain a bunch from having a convention that follows a set pattern. In fact, cutting out the middle man of an abstraction can make the code seem easier to read and more immediate.
That trade off flips when you have 100, 500, or (as is the case of Highrise) 2000 routes exposed to the public. When 95% of those follow the same pattern, there's big gain in the consistency of a convention. The last 5% are handled by outlet valves that allow you to declare whatever exceptions you need.
2) "The Seven Action Names Don't Help": I think the default constraint of 7 is the most important part of the positive effects you get from following REST in Rails for internal organization. Again, this isn't theory, but extracted experience from practice.
Rails used to require you to map everything by hand. Lots of people ended up with mega controllers that had 25 actions because there was no easy pushback. By the time the controller was too big it felt like too much of a hassle to break it up just to add "one more action". We still have GlobalController in Basecamp to remind us of what that was like.
Having the default conversion that turns /product/1 into show is also just pretty code. The two alternatives lined up are not very pretty. I'll take "def show" over "get(:member) do |id|" or "get "/api/v1/report/:id" do |id|" any day when it comes to a large, consistent URL surface.
3) "Assets are resources": I completely agree here. This will be addressed in Rails 3.1 when we get the asset pipeline going.
But as always, the proof is in the code. I'd love to see an even simpler routes system, but none of the arguments presented in the article gives any indication that the proposed ideas will lead to that. I've been both surprised and wrong before, though, so please do investigate.
Again, though, kudos for the presentation. I wish more people passionate about API design would take the time to do something as pretty. But with more concrete code examples, please ;)
I actually like the HTTP-style method approach. You mention pushback to prevent people from creating mega-controllers, and I think this takes it even a step further. It really ties the controller to the resource. As mentioned in the article, this is already how the methods are called in the tests.
With that in mind, stable conventions are of paramount importance if Rails is going to maintain its practicality when building large web applications. On the spectrum of poor conventions to good ones, Rails has been much closer to the idealistic end of pushing REST principles and the concept of resources over haphazard URLs and actions. We owe a debt to Rails and its designers for the abundance of REST in production today.
That said, I empathize infinitely with Adrian Holovaty. I love URLs and I want them to always be beautiful everywhere. It's true that Rails gives less obvious control over URLs than Django or Sinatra, but it does so for the reasons mentioned above. There are probably small changes that could be made to make Rails more URL-aware for those of us who would like to craft every URL with loving adoration, but those changes absolutely must be compatible with the consistency already embodied in the Rails routing system. I haven't thought much about what those changes might look like, but I agree with DHH that the post above feels very hand-wavy in the proposal department.
Just remember that we URLophiles are a minority. Rails must work well for the majority and they will never care about URLs.
get 'something/fun/:id', :to => "controller#action"
You can map just about anything that falls outside of the conventions with a variety of that.
Convention born of common usage is a strength of Rails.
I think simple routing systems, like Sinatra, are the way to go here.
From a simple library that does not get in the way, it's not too difficult to come up with a convention that matches your needs. The overall application then becomes simpler because I don't have to fight a heavy-weight routing system that misses the point.
Idea 2 is the way to go because it's resource oriented and you get useful stuff like 405's for free which you don't with the sinatra approach.
Please don't remove routing. Having routes is important - it makes the code more descriptive and easier to follow. All a route needs to do is map one URI pattern to one controller, i.e:
/blog -> BlogController
/blog/:post -> BlogPostController
/blog/:post/comments -> BlogPostCommentsController
I wrote a hack for Zend Framework last year to prove how this would work:
http://restafari.blogspot.com/2010/04/restful-php-applicatio...
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.
First, not everything your app will do is conveniently understandable in terms of resources, just like not everything code does is conveniently understandable in terms of operators. We have, thankfully, largely killed operator overloading and replaced it with functions. Why regress on function naming in our controllers? This is really a paypal_callback, not a PUT on the Paypal "resource", which doesn't even exist and if it did would tie across authentication, billing, and stats subsystems. (What does a PUT on Paypal even mean, anyhow?)
I also get hives when I think about including Rails default routes -- which are programmer-optimized, not user-optimized -- in publicly visible places, where they will get picked up by search engines and seen by copy/pasting users. example.com/categories/1/cards/5 is a part of your user interface... and it sucks. example.com/bingo-cards/holidays/halloween is superior in just about every conceivable way.
1) You can certainly have a paypal_callback method, if you choose. That's talking about the carrier, though, not the action. Presumably that callback means something specify. Like completing an order or authorizing a credit card check. Modeling your domain deeper like that makes it easier to follow and understand. But if you're either unable, unwilling, or uninterested in expanding your domain like that, you can certainly also just map paypal_callback to a controller with a action that corresponds to that.
2) example.com/bingo-cards can certainly work well if you know you entire namespace in advance. This can be true for things like CMS'es, but it's rarely true for user account based applications. For example, if your product has a /help section that's supposed to do something specific and a user creates another entity called "help" you're in trouble.
The /categories part establishes a namespace. So you can have both /categories/wonderland and /tags/wonderland and they can peacefully co-exist.
The ID part doesn't have to be a number either, but again it comes back to namespacing. If you don't use unique identifiers, there can only be one thing named halloween and it has to refer to the same entity. When that's true, go ahead, knock yourself out. Lots of Rails application is having a taste of two worlds with ID including permas, like /users/5-sam -- that's nice for SEO and still you can have two Sams.
Hope that clears up the confusion.
...ever A/B-tested that hypothesis? ;)
Routing is decoupled from those actions. You are not forced to use 'example.com/categories/1/cards/5', you can have (in this case) the #show action mapped to 'example/foo/some_card' if you want.
I've seen non-technical users balk at long, confusing URLs, but I've never seen one of them praise or even remember a short, semantic URL. From the few non-technical people (mostly family) who I work with on a regular basis, URLs are just things to click on to get somewhere. Some of them are confusing.
Having semantic, discoverable URLs is awesome for people that think in terms of URLs. It's kind of a non-issue for people that don't.
I don't want to go through the process of creating a new URL, figure out what its parameters will be, and then map those HTTP parameters to arguments to a server-side function. I want to magically link a client side action to a call on the server that may perform a side effect or return HTML, or both. The URLs are an implementation detail that I'd rather not think about.
Beautifully designed article and your specific example is a great attention to detail on the author's behalf.
Most of the need for the rewrite of the router came from the overhead associated with having all those (often unused) routes in memory.
My sinatra apps use very little memory and that is great for a lot of reasons.
I also realized that I don't like the rails convention of having a separate file for everything. Avoiding that has saved me lots of RSI.
I personally find sinatra routes more scalable than Rails routes because they are modular (defined within the resources). Rails routes are one monolithic file with a separate controller layer.
"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.
I think the routing abstraction is necessary and useful in larger application. Isn't it a very simple and clever syntax for the routing configuration is good enough?
I was introduced to Ruby through Sinatra. Developed all my web apps using that though I used to play around with Rails. I had an initial idea that Sinatra was meant for small apps, and for anything serious you should go Rails.
However that idea seems invalid now; the way I'm now used to Sinatra, it is kind of getting almost all the goodies of Rails without the Routing layer (which I find hard to follow - as mentioned by the OP).
Sinatra+ActiveRecord+ActionSupport+ActionView = Rails - Routing - ActionController
On the flip side, if you remove all the non-REST code from your controller to the extreme, like what you'd see when using the inherited_resources gem, the only code left will be your callbacks. DHH said this presentation needed to show some code to make the claim hit home. So the only code left to remove is the callback code.
How could the controller callbacks be made better, and more invisibly integrate with the routing muck? Rails 3 is getting the state machine gem added to core, so no doubt about this time next year someone will have re-re-re-written the routing code using the state machine api. Could the routing muck be made to be the controller callbacks? I always liked the idea of how the Seaside framework did it using continuations, even though in practice it wasn't quite as good. Everyone knows that creating a zen-simple state machine api using continuations is not fun by anyone's measure of the word "fun."
