<...>
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 
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?
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? 
--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.
Pat Maddox wrote: