ActiveResource find Updates
The ActiveResource find method just got a little bit of tightening with a new :from option. This option basically replaces the ability to call a custom method with a single argument to find and makes find a little less open-ended.
For instance, if before you were invoking a recent custom method:
Post.find(:recent) #=> GET /posts/recent.xml |
you will now need to declare the multiplicity or scope (:all in this case) as the first argument and the custom method as the :from option:
Post.find(:all, :from => :recent) #=> GET /posts/recent.xml |
You can also do the same for singleton resources with the :one scope:
Post.find(:one, :from => :latest) #=> GET /post/latest.xml |
And if you just want to manually specify the location from which to get the post, you can use the actual string URI:
Post.find(:one, :from => "/categories/1/latest.xml") #=> GET /categories/1/latest.xml |
So basically what’s happened is that the first argument to find has been tightened to allow either the resource id or the scope (:all, :first, :one) and any custom method or manual resource location has been moved to the :from option.
ActiveResource Custom Headers
ActiveResource was also recently updated to include the ability to set custom headers per resource.
1 2 3 |
class Post < ActiveResource::Base headers['X-MyHeader'] = 'ryan' end |
Every request from Post will now include that header.
Note: The original patch used custom_headers but was since changed to headers
It’s refreshing to see ActiveResource getting better and easier to use!
tags: ruby, rubyonrails, REST

You appear to mean :from option, buddy. Take care!
Wait, what happened here?
This: Post.find(:recent)
Now has to be written like this?: Post.find(:all, :from => :recent)
That sucks. That’s the exact opposite of where other parts of rails like simply helpful have gone to reduce all this typing :)
What was the reason this had to go away?
Nate, first of all Post.find(:recent) doesn’t have any way of distinguishing between records and collections. So right there it’s already a bit iffy. Second, Post.find(:all, :recent) just doesn’t follow the standard conditions of all other ARes calls. Adding :from makes it clear that we’re talking about fetching from a different-than-standard URL.
Short is not always better. Clear is better. Some times, even often, clear is equal to short, but not always.
Post.find(:recent) should ‘GET /posts/recent.xml’, not ‘GET /people/recent.xml’ as your first example shows, right?
Jim and Matthijs, you are both correct – I had some lingering typos/brain farts. Thanks for the proof-read!
I like Ruby on Rails, and these ActiveRecord changes are great and all… but what about long-standing issues, like support for foreign keys? I’m really waiting for better support for foreign keys, right now I have to resort to many ugly hacks to, for example, make sure that loading fixtures work with foreign key constraints. I also saw some trivial foreign key-related patches (such as documentation patches) in Trac, which are more than 3 months old, but never get committed. Is foreign key support a priority at all? And what about the use of prepared statements instead of building SQL queries in a single string?
Hongli,
You appear to be confused. The discussion here is about ActiveResource, not ActiveRecord.
“Short is not always better. Clear is better. Some times, even often, clear is equal to short, but not always.”
DHH is my buddha.
Thanks for very interesting article. btw. I really enjoyed reading all of your posts. It’s interesting to read ideas, and observations from someone else’s point of view… makes you think more. So please keep up the great work. Greetings