ActiveResource looks just like ActiveRecord, but a lot of the things you get for free with ActiveRecord aren't there with ActiveResource. One major weakness is the lack of association classes.
It's actually pretty easy to add custom methods on the server side which allow you to use find(:include) to return ActiveResource objects with their association class objects attached - for instance, if you write methods on the server side to support it, and patch ActiveResource's find(), you could easily call User.find(1) and get back a User with that user's Widgets attached. ActiveResource find() can do pretty much anything if you just have new keywords dispatch to new get() methods. It delegates to get() methods on keywords already, so you just follow that pattern and you can more or less send it anywhere. The key is the server-side methods that the get() methods call, but those aren't hard. All you really need on the server side is a reasonable understanding of routes and a #to_xml call on a collection which consists of both the User and their Widgets.
But there's a danger there. You might write code which assumes that ActiveResource models, like ActiveRecord models, will return  or nil for association classes with no content. If a User has no Widgets, @user.widgets should return . In fact, an ActiveResource application built on this assumption will raise a lot of NoMethodFound exceptions during development. This is especially true if you use ActiveResource models in form handlers. In fact the real danger isn't writing code with that faulty assumption but using it. You're in a controller, using a popular plugin, when suddenly everything blows up because you're missing methods on your models, but you didn't see it coming because they're only missing in some use cases. Even in the context of good TDD, code built on convention over configuration can blow up pretty badly if you're disregarding convention.
ActiveRecord attaches those methods automatically, but ActiveResource doesn't. Remembering to add them manually is pretty counter-intuitive. There's a simple way to handle this. ActiveRecord generates these methods when the application loads. ActiveResource can do the same thing. You need two parts - a server-side part and a client-side part. On the server, you need a method which generates a schema dump from the database, and on the client, you need code which attaches methods to model classes based on this schema dump. This is exactly how ActiveRecord generates these methods under normal circumstances; the only new addition is the translation to XML, for the sake of using a common network format.
On the server side, generating the schema is easy:
This gives you Ruby. There's a schema_format class attribute on ActiveRecord base; you might think the cleanest way to get XML from here would be to define a new option for that attribute:
ActiveRecord::Base.schema_format = :xml
Unfortunately, schema_format doesn't seem to actually do anything any more. In fact, if you want to dump your schema to a SQL file, you don't even use SchemaDumper; check out railties/lib/tasks/databases.rake for more detail. To dump your schema to SQL, you don't use rake db:schema:dump at all. You use rake db:structure:dump.
Obviously, the correct solution here is to change that. There should be a SqlSchemaDumper and a RubySchemaDumper, each instances of SchemaDumper, which should become an abstract superclass, and Rails should dynamically determine the specific subclass to use based on the schema_format class attribute. But I'm not going to lecture about it; there's no excuse for lecturing about it instead of just fixing it, and I'm not actually going to fix it, so my lecturing isn't worth much.
However, if I was setting up that fix, I'd then add in a third subclass - XmlSchemaDumper. Obviously, this would be the option to go for when writing a server-side Rails controller action to return an XML schema to a client Rails app using ActiveResource.
If you're doing this, fixing the schema dumping process is probably worthwhile; if not, you could do it all ghetto-style and just churn through the Ruby schema dump with regular expressions. That'd be lame, though. In fact this whole thing has me thinking pretty seriously about refactoring this stuff, just out of a general neat freak vibe, but we'll see what happens.
Anyway, on the client side, just to finish up, you get XML (in one way or another) which gives you tables and columns. Obviously, you can map this directly to resources. If your ActiveResource objects correspond directly to your ActiveRecord objects, you're basically home free. The only thing left to do is write a simple bit of Ruby metaprogramming whatnot that takes a list like this:
:users => [:widgets, :other_widgets]
And adds User#widgets and User#other_widgets association methods accordingly. I'm going to skip the details. It's an interesting subject but the post would get too long. In brief, use String#constantize and attr_accessor, and read the final four chapters of "Ruby For Rails" if you don't understand what's going on.
The assumption here is that you're mapping ARec server models directly to ARes client models. This isn't always the way to go. Resources aren't objects, and there are pitfalls involved in treating them as such. Mike Mangino said some pretty interesting things at Rails Edge about how making this distinction, between objects and resources, significantly clarified application design on some of his projects. However, there's a lot of pragmatic benefit in a one-to-one mapping - apart from anything else, you could in theory auto-generate both your ActiveResource and ActiveRecord models/foo.rb files from your schema, eliminating a great deal of repetition. So, if you are doing it this way, model your ActiveResource application load phase on the app load phase from ActiveRecord.
Update: I can't think of any excuse for not implementing this refactoring, except for lack of time, so I may in fact give it a whirl.