ActiveResource as a Web Servicification Tool

That’s right Web Servicification. Servicifying, just like the subtle art of Strategery, is an oft derided but subtly powerful part of my toolkit.

Or at least it is now. I have been working on a monitoring application so that we could figure out when things were going pear shaped — as opposed to finding out after the fact. This monitoring application was somewhat novel in that it successfully got me out of doing hard things of little quantifiable value and let me focus on doing easy things of much greater value (see above goal). Using RRD is a good example of outsourcing a hard problem  — what to do with all that data ?!?– to something that handled it for me. Not an especially hard leap to make, thanks to lots of SysAdmins who feel exactly the same way, but still, I’m really happy that I’m not collapsing data to keep my disk footprint somewhat finite.

This whole strategy of ‘doing more with less effort’ is really fun, I’m searching for something non geeky to try it in.  If I get the same efficiency boost in my personal life I’ll have enough time to write a best seller, become a kickboxing champion, or both.

In the context of my (geeky) monitoring app, Web Servicification is something else that gets me out of a couple of fairly hard to do things. Wait, let me back up a bit. Web Servicification with ActiveResource gets me out of a couple of fairly hard to do things.

The first is writing a web service. Go ahead and sneer at the difficulties of writing an XML consuming service, but until you’ve rolled your own in Java, you just don’t have that Juan Valdez “I wrote this one bean at a time” feeling.

The second hard thing this gets me out of is writing monitors for a bunch of heterogenous systems. We’ve got some things implemented in Java, some in Ruby, some in Perl, etc. I either slap a bunch of web interfaces on all of those systems, then write some centralized code to poll those interfaces, or I slap a web interface on my monitor app and let other people figure out which statistics are meaningful to them, and how often they should be updated.

A Web Service by Default

ActiveResource comes more or less enabled by default in Rails 2.0. Every method in a default generated controller can be accessed either by the UI or an REST action. Here is an example controller generated for one of my resources.

# GET /samples
# GET /samples.xml
def index

respond_to do |format|
format.html  #index.html.erb
format.xml  { render :xml => @monitor_instances }


# GET /monitor_instances/foo
# GET /samples/1
# GET /samples/1.xml
def show

# GET /samples/new
# GET /samples/new.xml
def new

# GET /samples/1/edit
def edit

# POST /samples
# POST /samples.xml
def create

# PUT /samples/1
# PUT /samples/1.xml
def update

# DELETE /samples/1
# DELETE /samples/1.xml
def destroy

Notice that the standard REST verbs are implemented in the same methods that handle rails application page requests. That’s pretty cool, and it means that you’ve got basic CRUD from the get go. The secret is in the render method (in bold above), which returns either a page or XML content depending on the requested format. If the request ends in xml, it’s assumed to be REST, otherwise it’s assumed to be a standard page request.

Routing for both REST and page based requests is provided in routes.rb:

map.resources :monitor_instances

provides routing access to the default methods defined above.

Accessing the Default Web Service

ActiveResource::Base is the class that abstracts the wire format and provides basic CRUD access to the resource. To access the MonitorInstance objects defined above, I could do the following:

class MonitorInstance < ActiveResource::Base
# define what you need in here


The ActiveResource based MonitorInstance acts similarly to an ActiveRecord based MonitorInstance:

monitor_instance = MonitorInstance.create(:name=>monitor_name,:monitor_instance_id=>,:frequency_id=>,:status_id=>@status_by_name[‘good’].id,:monitor_type_id=>@monitor_type_by_name[“stand_alone”].id)

creates a monitor with the parameters as specified above.

MonitorInstance.delete( OR


removes the monitor instance.

monitor_instance = MonitorInstance.find(1) finds me the monitor instance with an ID of 1.

removes that Monitor. So far, so good.

Find (not by ID)

What if I want to find something by a secondary attribute, like name? The default rails app expects qualifying parameters to be passed in a params hash:

monitor = MonitorInstance.find(:first,:params=>{:name=>monitor_name})

My MonitorInstances can be nested under other MonitorInstances. In the Rails app model, each MonitorInstance model specifies that it  belongs_to :monitor_instance.

This doesn’t quite have a corollary in the ActiveResource world. ActiveResource is concerned with abstracting basic access of web based resources, and that associations are not available via that abstraction layer. When I want to find a nested MonitorInstance, I do the following:

def get_monitor(monitor_name,parent_name = nil)

if(parent_name != nil)
parent = get_monitor(parent_name)
@logger.debug(“finding first instance of monitor #{monitor_name} under #{parent_name}”)
monitor = MonitorInstance.find(:first,:params=>{:name=>monitor_name,:monitor_instance_id=>})
@logger.debug(“finding first instance of monitor #{monitor_name}”)
monitor = MonitorInstance.find(:first,:params=>{:name=>monitor_name})


So I need to first get the parent resource, then make a request with the parent ID in the params hash, as indicated by the bolded text above.

Updating — Avoid Non Writeable Parameters!

It was hard to find any updating doc that didn’t just say “to update, just invoke the ActiveResource-derived object save method”. Which sounds great in theory, but didn’t work, because the default implementation of save POSTS all attributes, even those that are considered immutable, to the web service endpoint. For instance, my MonitorInstance class has an id field that is immutable. That field is posted with all other (mutable) fields. There is a method in ActiveResource to remove all immutable/protected attributes, but that method calls an undefined logger object to notify you that you are trying to modify an immuatble attribute, and an exception is raised.

To get around this, I stripped the immutable attribute — the id — out of the incoming params hash of the controller update method (in the Rails app) — see the bolded text below:

class StatisticsController

# PUT /statistics/1
# PUT /statistics/1.xml
def update
@statistic = Statistic.find(params[:id])

if(params[:statistic][:id] != nil)
logger.debug(“removing ID from input params!”)

respond_to do |format|
if @statistic.update_attributes(params[:statistic])





Nested Resources

The StatisticsController above handles all posts to Statistics resources, which are 1..N measurements associated with a monitor. In order to enforce that kind of scoping in the request path, I need to update the monitor_instances routes to scope the statistics routes:

#map.resources :statistics

map.resources :monitor_instances, :has_many => [:statistics]

In the statistics controller, I now need to always be aware of the ‘owner’ MonitorInstance. I do this by adding a before_filter, a method that gets invoked prior to every method being called:

before_filter :find_monitor_instance

This before_filter corresponds to the find_monitor_instance method, which returns the appropriate MonitorInstance:


def find_monitor_instance
@monitor_instance = MonitorInstance.find(params[:monitor_instance_id])

Now I have an attribute that I can refer to in my controller. Note that in all of the controller methods that handle both REST and page requests, I need to scope my model requests/updates with the @monitor_instance variable:

def index
@statistics = Statistic.find(:all,:conditions=>{:monitor_instance_id=>})

respond_to do |format|
format.html # index.html.erb
format.xml  { render :xml => @statistics }

I can also take advantage of RAILS path freebies. For instance, after a create request for statistic, I redirect to the appropriate monitor_instance scoped path like this:

flash[:notice] = ‘Statistic was successfully created.’
format.html { redirect_to(monitor_instance_statistic_path(@monitor_instance,@statistic)) }
format.xml  { render :xml => @statistic.to_xml, :status => :created, :location => monitor_instance_statistic_path(@monitor_instance,@statistic) }

monitor_instance_statistic_path generates a path that looks like {path to server}/monitor_instances/1/statistics/3.html or .xml depending on the requested output format.

Some Helpful Links:

ActiveResource RDoc

REST + ActiveResource

Comments from this Railscast

3 Responses to ActiveResource as a Web Servicification Tool

  1. arunxjacob says:

    One thing I forgot to mention is that the default generated views of a non scoped resource need to change to link to the scoped version of the resource. For example, the default parameter in a form_for method assumes a non scoped resource url as the post destination.


    needs to change to


    other redirects will need to be similarly changed.

  2. […] really like RRD, as I’ve mentioned before, it gets me out of the business of drawing graphs and storing data, both of which are hard problems […]

  3. Indies says:


    […]ActiveResource as a Web Servicification Tool « Wherever I go, there I am[…]…

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: