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).
Related
In the process of making an ebook, users have to edit its content, edit its metadata, choose marketing options, (such as pricing and distribution) and publish.
I started to put each everything inside the Book resource (contents, metadata, marketing options etc)
Then each step of the process (contents, metadata, marketing) is an action inside BooksController.
But Books started to grow a lot in terms of attributes and actions.
I'm wondering if it is better to force RESTfulness by creating singleton resources, each associated to their respective book.
The routes would be:
/book/12/content/edit
/book/12/metadata/edit
/book/12/marketing/edit
This seems more elegant, as each of these "resources" are RESTful and have few attributes each. But the resources are not objects (Marketings?).
Do you thing it's OK to create meaningless resources just to be RESTful and keep code in order?
Is there a better way to group similar attributes than create resources out of them? Thanks.
I'm porting a large PHP application to Rails and we have a fair few "ad-hoc"resources, such as admins have the ability to log in as another user with their permission, in order to correct issues etc. I would always complain that features such as logging in as other users should not be bundled into a huge monolithic AdminController as actions loginAsUser and logOutOfUserAccount. In our Rails app we try to visualize as much as we can in terms of resources, so using the example I just gave, we have an Admin namespace, under which there is a UsersController (/admin/users/:id) and as a sub-resource of users, we have a UserOverride resource (/admin/users/:user_id/override)... it feels really logical that we just POST and DELETE to this resource.
So getting back to your example, yes, I think you should break those sections down into separate resources. It certainly seems like BookContent should be a sub-resource of Book, and MarketingOptions too.
resources :books do
resource :content
resources :marketing_options
end
etc
This is both nicer to work with (more modular) and easier to visualize just from looking at the routes alone. You also get the benefit of really predictable path helpers:
<%= link_to("Marketing Options", book_marketing_options_path(#book)) %>
You can't try to force every conceivable route into a RESTful resource ideology though... if it feels like it's forced, then it probably is.
There's a decent blog post I wanted to link to that (despite some poor grammar) actually does a pretty good job of showing you how to think about your application in terms of resources... I can't find it though. I'll add a comment if/when I do.
EDIT | Just re-reading your original question and wanted to clarify: resource != row in database. A resource is anything you can conceive as a "thing"... I know that's a very broad statement, but just like an Object in OOP doesn't have to represent something concrete/material, nor does a resource in a RESTful design.
I'm pretty new to Rails 3 and I'm trying to understand the advantage of designing an application in a RESTful way. I don't need an API/Web Service. Don't need XML or JSON.
The application I'm building uses no CRUD at all. It is an app that gathers trade data via a socket connection and displays it to a user in many different ways.
I would like to visualize trades in different ways such as:
Most recent
Highest Yielding
Trades by State
Most active trades
Million dollar trades
Trades that are general obligation bonds
etc…
In the "Rails way" it seems that I would have a very overloaded index action. Or I could go against convention and just create methods in the trades controller like most_recent, highest_yielding, most_active, etc. But that seems to go against the whole philosophy of designing an app in Rails 3.
It just seems like the idea behind a RESTful approach in Rails is based around CRUD and falls short when CRUD isn't involved. Is there really an advantage to designing your app to be "RESTful" besides following a convention? I'm not really seeing the advantage here.
Plus, if I ever do need an API, I would imagine that it would be much better to design an API with an API in mind. My API wouldn't be a direct 1 to 1 match of my website which is built for human consumption vs a machine.
I'd appreciate any insight on this. Maybe I'm missing something here?
CRUD is actually involved when resources are involved. And since virtually every application has resources CRUD can be involved and is usually(if you ask me), the best way to do it.
The idea is that a resource has certain actions. You view a resource, you edit it, you delete it and some more. The methods like most_recent(or scope for this one) should be used in models and not controllers. Then, if you need to use that collection, you would just call something like :
#recent_posts = Post.most_recent
in your controller. Your controllers should not have much code, actually no business logic at all.
RESTful is very nice because it handles resources naturally. A controller should actually be handling a resource. If you think that something can be edited or created, then it should be handled by a controller.
Generally, i highly suggest that you take a deeper look and you will definitely see the advantages on your own.
I have idea how to do it. Code is not tested, I just wrote it without running.
Controller:
# trades_controller.rb
def index
# all scopes defined in model will be allowed here
# not good idea if you don't want it
if Trade.scopes.has_key?(params[:scope].to_sym)
#trades = Trade.send(:params[:scope])
else
# render error or what you want
end
end
Model
# trade.rb
scope :most_recent, order(:created_at)
# more scopes
View
# index.html.erb
link_to 'Most recent', trades_path(:scope => 'most_recent')
Your design should always take into account the requirements of your application first and the philosophy of the framework second.
If the philosophy doesn't fit your requirements or what you believe is the best way to develop your application then either ignore it, or, if the framework makes it too difficult for you to build like you think you should (which isn't the case in Rails imho), switch to another framework.
All of that doesn't have much to do with REST. For more info on why REST is considered a good idea (for some, not all, things), see the following SO Q&A's: Why would one use REST instead of Web services and What exactly is RESTful programming.
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.
I am looking at implementing URLMapping for a personal project. I am already aware that solutions exist so please do not answer suggesting I should use one.
What I want is to harvest the opinions of fellow developers and web users on URL mapping implementations. Specially I would like you to answer:
Which is your favourite implementation?
What do you like about your favourite implementation?
What do you not like about your favourite implementation?
How would you improve it?
I would like you to answer from two points of view:
As a developer
As a user
I would be grateful for any opinions on this matter, thanks!
I've only worked with django's URLConf mechanism. I think the way it relies on the urlpatterns variable is a bit flimsy, but I like its expressiveness in specifying patterns and dispatching to other url configurations. I think probably the best thing is to figure out your URL scheme first, and then try out a couple of solutions to see what matches best. If you're going hard-core REST using the full complement of GET/POST/PUT/DELETE, and checking the user agent's Accept headers, and all that, django will, by default, have you splitting your logic between URL config files and view files, so it might not be the cleanest solution.
However, since it's all Python, you might be able to do some more complex processing before you assign to urlpatterns.
Really, you want a system that does what you need. Your URL scheme is your API, so don't compromise on it based on the tools you use. Figure out your API, then find the tools that will let you do that and get out of your way.
Edit: Also do a google search for "URL scheme design." I found this without much effort: http://www.gaffneyware.com/urldesign.htm. Not comprehensive, but some good advice gotten from looking at what flickr does.
Well, I should have noticed the url-routing tag shouldn't I? :-) Sorry about that.
jcd's experience mimics mine - Django is what I use too.
I like the fact that the routes for an app reside within the app (in urls.py) and can just be included into any projects that might make use of that app. I am comfortable with regular expressions, so having the routes be specified in regex doesn't phase me (but I've seen other programmers scratch their heads at some more uncommon expressions).
Being able to reverse a route via some identifier (in Django's case by route's name) is a must. Hardcoding urls in templates or controllers (view in Django) is a big no-no. Django has a template tag that uses the reverse() method
The one thing I wish I could do is have the concept of default routes in django (like Rails does or even Pylons). In Django every route has to map to a view method, there is no concept of trying to call a certain view based on the URL itself. The benefit is that there are no surprises - your urls.py is the Table of Contents for your project or app. The disadvantage is that urls.py tend to be longer.
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.