in order to better understand how RESTful works in Rails and thus become better at producing such code, i would like to manually create a resource from scratch. I generally know how to setup routes, controllers and the likes, but i would be interested in checking out some tutorial(s) that describe just that in detail.
Do you happen to know of anything ?
I would first advise you to get your REST concepts cleared. In my opinion, REST is fairly misunderstood concept in the community. I would recommend understanding it first without sticking to rails or any other technology for that matter. Ryan Tomayko has written a killer blog post about it. You also might want to read Roy Fielding's paper, if you are into it.
Once you understand the concept clearly, implementing it in a technology is not so hard. For rails, create a blank controller and start adding the actions one by one based on your understanding of REST. Think about exactly are you doing in the action. Are you fetching the data and showing it to the user? In that case, you need to make sure that the action can only be called with a HTTP GET verb. Are you updating a record in that action? You probably should only be accepting a HTTP PUT verb for that action and so on... Here are some resources found on some quick googling which look good to me.
http://blogs.sitepoint.com/2008/02/04/restful-rails-part-i/
http://s3.amazonaws.com/ozonesoft.net_public/RESTfulRails.pdf
I would recommend reading the standard documentation of routes in rails. I think that's enough. But to understand what makes an app a RESTful app and what doesn't is the key.
Related
What criteria do you use to decide whether or not to nest resources?
In the past, I have chosen to nest when the index action on a resource makes no sense without scoping to an associated resource (the parent).
Even as I write the above criteria, I realize it is ambiguous at best.
A colleague has stated:
Nest resources because it captures the relationship of the associated models visually in the url structure... And it makes it easy to modify the url to get back to just the post. If I see /posts/123/offers/555 -- I know that I can go to /posts/123 to see my post. Where as if I just saw /offers/555, I'd have no way to get back to the post other than manually navigating through the site.
To me, manipulation of the url by users should have no bearing on the architecture of the application, and flies against what I understand to be the generally held principle that nested resources should be avoided if at all possible. Additionally, this argument would seem to support multiple levels of nesting, which again, pretty much every article I read advises against.
What has been your experience?
I nest routes, as you put it first, when the later things in the route doesn't make sense without the former. Comments on a blog would be nested under resources articles because, though perhaps you want display an individual comment on it's own page (who knows why...), a comment belongs to an article.
This also has controller implementations. If you know the article, then you can find the specific comment scoped to the article. This makes for more effective queries.
Also, your colleague was correct that you have to deal with users messing around with your routes, though he had the wrong reason. It isn't for their convenience, but for their security.
Let's take an Amazon-like app with users and orders. If I am at users/5/orders/2 then I think "hey! I can just change that 5 to a 4 and then see someone else's orders!" If you don't scope orders, then the controller-level logic for authorizing a user to view orders/2 becomes far trickier. Scoping to the user allows for current_user.orders.find(params[:id]) in the orders controller. Current user can be found based on authentication so that they cannot just swap ids in the URL and become someone else.
I've been reading up on REST lately and it's become seemingly clear that verbs do not belong in URIs. If this is the case, is the standard "resource/1/edit/" that particularly shows up in Rails a violation of REST? And if so, what alternatives are there?
Don't confuse CRUD with REST.
Rails provides "Resourceful Routing", and the actions within the URL simply provide a resourceful interface. The HTTP request verbiage still remains RESTful, which is what counts.
Here is an insightful article which does a fairly good job explaining REST/CRUD (specifically in Rails).
What are the cons in using the generic route:
match ':controller(/:action(/:id(.:format)))'
I was told it is not recommended yet I do not see why. What problems can I get from using this?
Because it's easier to implement REST if you use the opposite ordering, ':controller(/:id(/:action))', and rails now has more convenient ways to get the proper HTTP verb using explicit resource routes.
Understanding the basic principles of REST will make it easier for you to expose an API, should you choose to go down that route, which embraces the principles of HTTP. It also tends to keep you from doing certain unclever things, like making it possible to delete records using a GET request. (The uncleverness might not be discovered until Google or your internal search bot decides to index all the links to :delete actions.)
The basic idea is that a GET /Url should imply fetching a resource. When you put the action first, the resource is semi-obscured, and you're accidentally opening the door to potential errors because all of the HTTP methods can be used to call destructive actions. Using an HTTP verb-centric approach, you can send an UPDATE request to the same URL as the SHOW request.
A specific answer to your question, which I understand to be understanding cons of the generic approach:
One significant risk is that you make every single controller action (non-protected) available to your users. It gives them the ability to access your entire 'tree' of controller actions, which may or may not be desirable depending on your situation.
In addition, you give users the ability to GET rather than POST, POST rather than GET, etc.
The comment above it that is generated explains it pretty nicely.
# Note: This route will make all actions in every controller accessible via GET requests.
This means that you could theoretically do a GET request on a route that is only supposed to be accessible via POST. ie. You could do add a route called /postable to a user object, which should only be POST'd to, but if you use the rule above you can also do a GET request on it (with empty parameters).
You don't really get problems, per se. Instead, you lose out on the advantages you gain from using resource routing:
A common pattern that helps simplify controller design
Free RESTlike handling of HTTP verbs (GET, PUT, POST, DELETE)
Peace, Love and Happiness*
You can find out more about resource routing by reading the Rails Routing Guide.
* Peace, Love and Happiness not available in all areas. Terms and conditions apply.
I've been messing about in rails the past 2 months and so far everything's going well - but there's one area I'm a little doubtful on.
I keep hearing about the joys of RESTful rails resources: that is, a 'resource :foo' in config/routes, and your 7 restful actions in the controller.
Except for very simple things (eg stuff that's 99% done by running 'generate scaffold'), I find it's less convenient to try squeeze my project functionality into that approach than to just match urls in config/routes one-by-one and do each action as needed.
But I keep getting the sense that I'm wrong, and that in all but the most extreme circumstances, RESTful resources are the way to go.
So:
(a) Can anyone offer an opinion on this?
(b) For experienced rails folks, what % of your routes in a typical project are :resources and what % are coded action-by-action?
Cheers...
Resources are convenient, but they are not a "one size fits all" feature. Some things just don't make sense with the 7 methods.
Keep in mind that you can:
Exclude specific methods with :except.
Include only specific methods with :only.
Add your own methods to the resource.
So they aren't as inflexible as you may think. But if, after taking those 3 points in mind, the resource just doesn't "feel right", skip it! REST was never meant to replace regular routing, it just tries to abstract away the most common use case.
If you skip out on RESTful resources completely, you'll be missing a ton of free functionality. Use it wisely and you'll be fine.
Generally I start a project with the REST architecture in mind. I build out my basic functionality this way, but as the project/website progresses I write more and more views that do not fit into the RESTful architecture. Marketing sites and parallel functionality are perfect examples of this.
Here is an article on the approach:
http://ablogaboutcode.com/2010/11/22/to-be-or-not-to-be-restful-ruby-on-rails-best-practices/
Before you get started, here are some questions you might want to ask yourself:
Does this controller/view deal primarily with an object/entity like a Post, Blog?
Are create, update, delete, edit and new actions all going to be available on the web?
As a guideline, if you answer YES to these two questions, then it’s probably best to start with REST and expect that you will eventually use the architecture as a building block for additional actions and views you might want to perform. Otherwise, pick a URL that best represents what the action will show or do (/archives, /tour, /december-offer) and make sure you use the proper HTTP Protocols (GET for display, PUT for update, DELETE for removing and POST for creating).
I am pondering on using a Restful implementation in Rails. I'm asking myself if it's the way to go.
Should I always go for a Restful implementation or not?
I think there really isn't much other option as far as Rails goes. You would just be fighting against all the design decisions and sensible defaults that Rails, as a framework, has already made for you.
Think about all the provided shortcuts for routing, pathing, forms, etc. I think you would end up just spending more time/effort on a non-RESTful implementation.
The first thing to sort out is what REST really means. Fundamentally it is about utilizing HTTP efficiently and correctly. That is, GET requests don't modify anything, PUT requests are idempotent, etc. The notion of uniquely identified resources just sort of falls out of this optimal usage of HTTP. The beauty of REST is that you gain the maximum programmatic benefit out of HTTP, making things like caching, proxying, and automatic retrying able to work fairly well without any knowledge of the application whatsoever. Dare Obasanjo wrote a nice rant on the topic of REST misunderstanding. This contrasts heavily to something like SOAP where you have an heavyweight envelope format that uses HTTP as nothing more than a glorified transport layer.
Now when it comes to Rails REST there is a whole nother thing going on, and that is Rails' convention over configuration. Rails REST is just a thin baked-in layer of tooling to make it easy to define CRUD operations on resources you define. Note that these resources don't need to correspond to ActiveRecord models, and certainly using Rails resource routing is not a pre-requisite for designing a RESTful application. What Rails gives you is an extremely handy default for dealing with things that fit the model of a CRUDable resource, however you shouldn't hesitate to define additional methods on top of resources, or to forego resources altogether if you have pages that don't really seem like resources (eg. reports).
The bottom line to keep in mind is that it's not one or the other. Rails RESTful helpers are using the same primitives that have always been in Rails. You can use both together and they jive nicely.