Is ActiveResource fundamentally flawed?

Question

Several developers from different teams have independently told me that ActiveResource was a flawed idea. The most common criticism I hear is that it was a mistake to design it to have an ActiveRecord-like interface. I also hear complaints about the way errors are handled - or swallowed. One developer actually created his own gem to provide the same functionality as ActiveResource (a framework for models based on RESTful resources).

I am new to ActiveResource, but when I look at the code and experiment and see how it works, I struggle to see where the resistance is coming from. It seems to based in clean, solid concepts. I've even heard it's too heavy! But in my examination, I find it light and fast.

So with all this controversy about ActiveResource, I turned to the Web for answers. Surely, there must be stacks of blog posts about why ActiveResource should be canned in favor of X. After all, I can sure find posts about whether DataMapper is superior to ActiveRecord. So I've searched and I've searched and ... nothing. Not a single thing. I can't find a single page on the Internet making any criticism of ActiveResource (aside from blanket criticism of REST). I can't even find a proposed alternative. It has the support of the Rails core team and it seems to be the de facto standard in the community.

Bottom line:

Is there a controversy about ActiveResource? And if so, what is the nature of the debate? Are there alternatives?

Emarie

You seem to know more about the braintrust behind the criticism than I do. Not convinced this is a good SO question, though. – Telluric

Where should it be if not here? – Emarie

Maybe programmers, or somewhere where it's not just an argument. See the "not constructive" close text. Another option would be to actually include the negative side of the argument--if nobody except you has heard it, it'll be tough for anyone to address it, even if it was on-topic. – Telluric

This is a question about a very specific technology, not about programming in general, so SO seems more appropriate than Programmers. And I did mention the 3 most common criticisms I've heard. – Emarie

I've edited the question to address your concerns and hopefully yield constructive answers. – Emarie

Whatever; seems like that (a) you can't find anything about it anywhere, and (b) nobody has had much to say might in itself be an answer, but ok. – Telluric

you might want to check out the Yehuda Katz presentation at this years RailsConf - certain issues are brought up there in regards to presentation layer and ember.js. – Denaturalize

Thanks! Ok, that's a start, but he mainly just says it's broken and nobody uses it without giving a lot of context. It's as if everyone already knows this and doesn't feel a need to talk about it. And yet it continues to be developed. confreaks.com/videos/… – Emarie

@EbenGeer actually, it was removed from Rails proper for Rails 4.0. The main issue is that unlike SQL databases, a Rails backend is extremely inconsistent (I provide some examples in my talk), so the nice conventional solution in ActiveRecord doesn't work well for ActiveResource. I am not opposed to the concept of ARes in general, but we need better conventions around a Rails backend to make it really work. – Bluh

Thanks for the explanation Yehuda! I keep replaying your presentation. It's starting to click for me... – Emarie

@YehudaKatz , so the nice conventional solution in ActiveRecord doesn't work well for ActiveResource. what do you mean ?As for me general conventional solution in ActiveModel works good in ActiveRecord and ActiveResource – Ringe

Answer 1

I have worked with ActiveResource extensively since 2007 and have built and maintained a multi-service distributed architecture using ARes over the period when Rails went from v1.2 to v4.0. In my opinion ARes is fundamentally flawed as a public library in its current form, but it contains a lot of good ideas which can be put to use within individual systems. I gave a talk about what we did at my company to migrate away from ARes.

A big reason people don't like ARes in practice are because of poor maintenance or implementation details they disagree with. Things like the error message handling your colleague mentioned fall under this category. Also, over time you'll find things breaking unexpectedly due to ill-advised one-off improvements or bug fixes, or even Rails internal changes percolating up (eg. when the YAML-pocalypse hit last year, we suffered catastrophic breakdown in our ARes systems). But all of these things can be improved with better maintenance and better vision, it's important to separate these issues from the fundamental issue.

What I've come to believe, and what Yehuda alludes to in his comment above, is that ARes fails because REST APIs have no general concrete semantics. Even leveraging the best of Rails conventions, HTTP API semantics are flimsy at best.

Contrast this to what ActiveRecord does, it generates SQL: a well-defined declarative language for selecting rows of data. SQL is based on the relational model which gives us mathematical definitions of what a query means based on different clauses. This mathematical underpinning is what allows something like Arel to create a composable SQL DSL in ruby. In a SQL database, any syntactically correct query can be executed (even if it's too slow to be practical) because the engine is designed to formally parse and map SQL statements to provably correct implementation that manipulates and fetches the underlying data. So when you build an ORM like ActiveRecord on top of this, you have very strong guarantees in the underlying system. If you generate valid SQL the engine guarantees it will work, if you generate invalid SQL the engine returns you an error. And even with the standardization of SQL, it's worth noting that every database has a separate ActiveRecord adapter to ensure correctness and proper mapping to ActiveRecord features. Each of these uses an underlying driver to guarantee correct wire protocol implementation to the running database. All of this code has quite a large amount of specification and maintenance behind it, all of which enables the benign elegance and reliability of today's ActiveRecord.

Now consider an HTTP API and its backing? It could be any database technology under the sun or none at all! It's most likely written in-house and serves up only what is necessary for the business function. Unlike a database which carries in its schema all the necessary information about the operation of generic queries, an HTTP API is completely decoupled from any underlying storage mechanism or business logic. Even if an API provides a standard for how it uses query params, there's no self-documenting definition of which filter or sorting options are available. Heck, even checking the validity of params is not guaranteed, as often as not an API will just swallow up or ignore an invalid param.

All that said, ARes is very convenient, but it's built on quicksand. The ideas and conventions it uses are handy, but they lack a cohesive vision and stability to be reliable. Personally I think rolling your ARes look-alike with its own conventions and solid specs which you can then apply to your service implementation is not unreasonable.

In terms of building a foundation on top of which something like ARes could make sense, Yehuda Katz and Steve Klabnik's excellent JSON:API specification is a great community project that will provide one very important building block of such a foundation, however it's worth noting that it still doesn't come anywhere near a specific database driver in terms of semantic guarantees and derivable functionality. I suspect that a really good ARes-like library to leverage JSON-API will look significantly different from what it does today to better embrace the gray areas implicit in an adhoc API compared to a RDBMS.

Edit: JSON:API has just hit 1.0 after a very intense two years of debate and feedback from diverse communities. I would estimate the amount of work put into this spec is a couple orders of magnitude more than ActiveResource ever achieved. Although it's a different abstraction level from ActiveResource, JSON:API pursues a similar goal of providing standard semantics so that APIs are easier to produce and consume. Looking at some of the implementations gives a good idea of how much leverage JSON:API can provide.

Batik

Is there a chance that you publish your ARes alternative library someday on some open source license? It looks like very neat piece of code, I recently start working on API client application which uses ARes to map to remote AR models and I would love to try. – Ropy

The code I show in my talk is quite likely to become open source at some point (as part of a general MUBI client gem when we release an open API). The problem is it's nowhere near ready to be released as a general purpose gem because we are really solving a very narrow problem for ourselves and as soon as we try to generalize it to all APIs the feature requests are sure to come flooding in and we don't have the bandwidth to properly support what would be a sizable public project if it got any kind of serious adoption. – Batik

Answer 2

ActiveResource has been pulled from Rails in Rails 4.0.

A lot of people just use RestClient or HTTParty or another library. Those libraries are generally regarded as simpler and easier to use.

Clause

RestClient and HTTParty are not a replacement for the features of ActiveResource. – Emarie

ActiveResource does a little more than the standard RestClient or HTTParty. JSON is automagically decoded and represented as objects. It works with Rails I18n localization out of the box. It also keeps an error hash similar to ActiveRecord/ActiveModel so it's easy to present in the flash. So you get a lot out of the box with AR, vs just a plain rest client. Really depends on what your needs are. – Vaclav

@EbenGeer activeresource generally has more features and conventions, but you can use all 3 libraries for the same purpose, more or less. – Clause