Why ActiveResource will flop...

<...>

Rails is built on _extraction_. It seems to me that ActiveResource -
along with all the upcoming REST pixie dust - has been dreamt up before
actually being used in succesful apps.

<...>

To me it seams that your troubles and doom scenario is more dreamt up :slight_smile:
Can you provide an example of refactoring which would break anything, assuming
that public interface was more or less designed?

Regards,
Rimantas

Your original question was "Is there any publically available app exposing an ActiveResource api?" While I didn't answer that, what I did do was provide a publically available app that exposes a REST interface (as does YouTube, BTW). I don't perceive WSDL is not a solution to changing APIs.

An answer like "they have a stable interface" implies that there is some "pixie dust" solution to unstable interfaces. It's true that Rails does auto-discovery of the implementation details of your app. It's not so obvious that a Web Services client will need (or whether they should need) the same level of transparency down to the nuts and bolts.

If you return a list of cities for a zip code, then your client doesn't need to know much more than get http://myfineapp.com/geo/cities/10012. What's more stable than that? The tighter you couple, the more brittle things become and the more you'll have to worry about refactoring. If you decide you have an incredibly cool new API you want to publish, then keep the legacy one for legacy clients. That's what everyone did with DLLs, COM, CORBA, and pretty much everything else that involved consuming someone else's code using established interfaces.

No?

Steve -
I'm with you 100% that REST APIs are excellent. ActiveResource is
trying to do much more than that - it reflects on the fields of the
table, just like ActiveRecord, and exposes them. Being that the API is
just a reflection of the underlying schema, there *is* no way to keep
the legacy API around.

Does it reflect on the fields of the table, or on the attributes of
the model (which
may be fetched from the DB table, but may be defined in the model itself).
In the case you must change some field in db - why not just add a method to
your model which maps old name to the new field. Is there anything I am missing
what would not allow this?

Regards,
Rimantas

By default it reflects the attributes, but you can customize it with
to_xml. For instance if you rename an attribute but want to keep the
old one around, you can specify that. Check out the to_xml docs.

And really, how often does your app change things around? Do you
really like breaking your own app's compatibility?

For a real rails app that's compatible with ActiveResource *right
now*, check out Beast: http://beast.caboo.se/. Check out my intro
article: http://weblog.techno-weenie.net/2006/12/13/taking-ares-out-for-a-test-drive

But yes, ARes was dreamt up before being used in a site. A few of us
in core started fleshing it out as we needed aspects of it. But,
since it's not really proven in production environments, it remains
unreleased.

Another thing: who says the xml in your app has to map to
ActiveRecord? ActiveResource sees xml and posts it. It could easily
work against a compatible php or python app too.

If you change your implementation that drastically, will the API still
function as expected in the first place? Who goes around wantonly
changing the database schema without making major enough changes that
clients shouldn't be updated?

Even so, there are ways around what you're talking about. The problem
is that you want to hang on to legacy APIs while updating your code;
thats not a "normal usage" so Rails/ActiveResource doesn't address it.
Why glop it up for everyone else just because a few people need to
make it work the way you describe? I'd wager a good majority of
developers won't encounter something like you describe.

And though it's not directly handled, Rails/ActiveResource does,
provide other, less easy ways to accomplish what you describe (just
like ActiveRecord has ways to fit into a legacy DB). Most of them
have been suggested here.

I fail to see a problem here, but then again, I may not understand
your whole situation.

--Jeremy

Now, update to the latest src. Did the client break? If it does, than
ActiveResource isn't very useful.

If the client breaks, than the developers are doing a poor job.
Making an external API is making a commitment to your users. If you
want to make crazy schema changes now, just realize you'll have to
provide some backwards compatible way to access the old service.

- Use XSL to transform the old XML to the new XML.
- Take the hash data of the old XML hash and fill your recently
modified models with it.

Or, you could just deprecate it and provide an ajax widget (zing!)
There's nothing in ActiveResource that says the server has to tie the
data directly to the model.

This list of reasons is also why code libraries have flopped.

wait............

You're right, if you're cavalier about making changes like the ones
you listed above, then client code will blow up. That's not how
public libraries and APIs work though. You keep the API backwards
compatible, so even if you renamed a field/method you would have the
old one (and perhaps mark it as deprecated).

I will agree that it can be dangerous because there are so many Rails
developers that use the Rails magic without knowing anything about
Ruby. But I think I probably wouldn't find their APIs useful (nothing
I couldn't write in a couple minutes with script/generate), and I'd
probably be scared to use their API for more reasons than them just
breaking it.

Pat

It seems the consensus on this list is that if you want to use
ActiveResource, you have to give up making changes, refactoring, or
agile development - or at least work very hard if you want to do so.

To met, that defeats the whole point.

Any bets on whether they'll be even one succesful app in production
within 12 months with heterogenous clients (that is, written by other
developers, outside the source tree of the app, even in different
lanaguages) consuming ActiveResource API's?

Anyone up for my earlier challenge?

It seems the consensus on this list is that if you want to use
ActiveResource, you have to give up making changes, refactoring, or
agile development - or at least work very hard if you want to do so.

To met, that defeats the whole point.

I cannot imagine why anyone believes that. If you're going to provide
an API, the problem has to be pretty well understood, and the API is
a contract of sorts.

ActiveResource makes it easy to both provide and consume the API.

Why would you see it as an impediment to progress?

Any bets on whether they'll be even one succesful app in production
within 12 months with heterogenous clients (that is, written by other
developers, outside the source tree of the app, even in different
lanaguages) consuming ActiveResource API's?

Oh, heavens, I'm tempted to take that bet! Expect that I'm not so sure
they'll be consumed in other languages.,

Doesn't everyone use Ruby for everything from now on? :slight_smile:

It seems the consensus on this list is that if you want to use
ActiveResource, you have to give up making changes, refactoring, or
agile development - or at least work very hard if you want to do so.

I guess I didn't make my point clear earlier. If you change your API,
will clients still function the same? Or will you have to make
special cases for them, regardless of what tools you use create the
API?

For example, say you build a webservice and change the name of a
function or move a database table. Now you have to go back and change
your code in the first place, correct? So, how is this any different
than using ARes? Make a special case, move on with your life. New
clients and those who can update will; those who won't can be caught
by the special case code.

Even further, if you make huge sweeping changes, your clients are
going to have to update anyhow (and I see changing database schemas as
a pretty big change...).

I fail to see the difference in effort here.

Any bets on whether they'll be even one succesful app in production
within 12 months with heterogenous clients (that is, written by other
developers, outside the source tree of the app, even in different
lanaguages) consuming ActiveResource API's?

Done. I'm running our dorm security app on our campus here on Rails
Edge. It uses ActiveResource and interfaces with a Python application
I wrote last year and a Perl app (that used to interface with a Java
application) that someone else wrote way before my time. It has about
1000-2000 users a day. What do I win for the bet? :wink:

--Jeremy

Almost any database or class refactoring:
* Rename a field
* Rename a method
* Move a field to an associated object
* Change a method signature
* Etc.

This is where the misunderstanding lies. Active Resource is not tied to
the model or the database in any way. It merely reflects on the XML
returned. Yes, we have convenience methods like to_xml for Active
Records, but that's merely convenience. You can generate your XML any
way you like.

Remember, Active Resource is the client side of REST. What you do on
the server side, to keep the XML returned stable, is entirely up to you
and entirely orthogonal to the concerns of Active Resource.

It seems what you have a beef with is ActiveRecord#to_xml. Which is
fine. Keeping API XML consistent as the application evolves is an
interesting challenge. It just doesn't have anything to do with Active
Resource.

It seems like you made a statement and then took that as consensus,
when the majority of developers here have disagreed with you.

Any time you have a public API, you have to be careful about making
changes. This doesn't mean you can't make them, but that you just
have to be careful and keep your API backwards compatible. It's
really not that hard of a concept.

Pat

And of course you can get around that restriction by popping the word
'Beta' somewhere on
the accompanying web page.

:slight_smile:

Pat Maddox wrote: