Heading image for post: RailsConf Nostalgia: Remembering ActiveResource

RailsConf Nostalgia: Remembering ActiveResource

Profile picture of Mary Lee

This year at the final RailsConf, the atmosphere was incredibly nostalgic and celebratory, if perhaps a little bittersweet. Many of the talks spent time looking back on how far we've come, including Robby Russell's "The Rails Features We Loved, Lost, and Laughed At". Robby's talk brought back to light an old library that I hadn't thought about or used in years, ActiveResource. Once it was mentioned, it seemed like it kept cropping up during the conference, from DHH's fireside chat, to conversations in the hallway track, to notes on the public board about things people would like to see more of. So what is it, and why was it ultimately dropped from Rails? Let's talk about it!

What is ActiveResource?

ActiveResource is an api wrapper that provides an ActiveRecord-esque experience to working with RESTful services. It supports the entire CRUD cycle for resources, and both basic and token authentication.

For each resource in the api, you would create a class, and then specify the site and authentication strategy as class variables.

class Blog < ActiveResource::Base
  self.site = "https://www.hashrocket.com"
  self.auth_type = :bearer
  self.bearer_token = "foo123"
end

From there, you could start treating your new class almost as if it were an ActiveRecord model. When querying, ActiveResource would expect a JSON response from the api, and would take each element of the returned JSON object and set it as an attribute on the object.

# Execute a GET request to "https://www.hashrocket.com/blogs/1.json"
blog = Blog.find(1)

# Example GET response:
#  { "id": "1", "title": "About ActiveResource", "author": "Mary Lee" }
blog.title = "About ActiveResource"
blog.author = "Mary Lee"

You could also update or destroy the resources.

# Updating would execute a PUT request to "https://www.hashrocket.com/blogs/1.json"
blog.title = "Remembering ActiveResource"
blog.save # => would return a boolean value

# Destroying would execute a DELETE request to "https://www.hashrocket.com/blogs/1.json"
blog.destroy # => would return a boolean value

It's a neat library, providing a very "Rails-y" way of interacting with an api. You can check out more of the docs on rubydoc.

Why was it dropped from Rails?

ActiveResource was removed from the Rails core code in version 4.0. Officially, according to a blog post linked from the release notes, the main impetus behind the removal was lack of maintenance and dedicated maintainers within the core Rails team.

Unofficially, there were many problems with the library that were in desperate need of addressing, and with the rise of other libraries like RestClient and HTTParty, it was becoming easier for developers to set up their own custom integrations with apis outside of the limitations imposed by ActiveResource.

Where did it go wrong?

Today, ActiveResource has widely fallen out of favor, with most use cases existing as part of legacy systems. Under ideal circumstances, ActiveResource makes it incredibly easy to interface with external services. However, it breaks down whenever customizations to the expected behavior are needed, which would often be the case if the resources being consumed did not fit into expected patterns. The problem continues to be that there is no firmly defined set of rules that REST apis have to follow for an implementation to work; HTTP apis are the wild west, and while best practices exist, there is no enforcing them.

This is a stark contrast to how ActiveRecord works. Using structured commands within a defined language (SQL) to communicate with a database allows ActiveRecord to be opinionated without putting a burden on developers. ActiveResource, in contrast, is opinionated but built on a flimsy framework, making developers have to fill in the gaps as best they can. So while ActiveResource was built to mimic ActiveRecord behaviors, it couldn't quite support the featureset developers wanted.

Final thoughts

I remember using ActiveResource for an internal api between two Rails applications in my first job as a junior developer in early 2013. As the implementer of both the api and the consumer, it was easy for me to set up everything to meet the expectations ActiveResource had with regards to headers, authorization, and format. This made ActiveResource feel like a huge boon to me, so it was disappointing to see halfway through the year as we upgraded to Rails 4 that the library was moved to a separate gem.

Ultimately, that project was the first and last time I would ever use ActiveResource, but I still remember it fondly, and after RailsConf, I know that I'm not alone. Thanks for the memories, ActiveResource!

More posts about rails railsconf activeresource

  • Adobe logo
  • Barnes and noble logo
  • Aetna logo
  • Vanderbilt university logo
  • Ericsson logo

We're proud to have launched hundreds of products for clients such as LensRentals.com, Engine Yard, Verisign, ParkWhiz, and Regions Bank, to name a few.

Let's talk about your project