One of ActiveRecord’s greatest strengthes is its fluidity. Change a col
in your db, restart, wham!, new class.
This type of behavior is great for internal code. But for published
interfaces, it’s the exact opposite of what you want. Let’s say I have
a calendar web app, and expose a web service - via ActiveResource - for
you to hook in your local GUI app (or command line app, or complenetary
web app, or whatever you use ActiveResource for):
How would you feel if your GUI app broke every time I refactored?
How would I feel if I couldn’t refactor because doing so will break all
those GUIs?
Thought so.
A web service interface needs to be stable, hiding the implementation
and any changes in it. It needs to be decoupled from changes ot the
internal schema.
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. Is there any publically
available app exposing an ActiveResource api? Does it have any external
clients?
I’m all for REST, and I’d love to see a RESTful competitor to SOAP, but
it needs to be stable, static, decoupled from internals, and
discoverable via something like WSDL (yes, WSDL can be used for REST
too.) I think the Rails community is the best posed to make it happen -
but not like this.
(I’ll end my comments by pointing out that I think Rails is great. I
hope my constructive criticism is received in the spirit it’s intended.)
Amazon estimates that > 50% of its Web services are accessed via
REST. Seems like someone bought into it.
<…>
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
http://rimantas.com/
On Dec 25, 2006, at 1:33 PM, Robert J. wrote:
Steve R. wrote:
Amazon estimates that > 50% of its Web services are accessed via
REST.
They have a stable interface. I’m all in favor of REST, mind you.
What I don’t see working is a shapeshifting API made public.
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 R. wrote:
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.
On 12/25/06, Rimantas L. [email protected] wrote:
may be fetched from the DB table, but may be defined in the model itself).
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.
–
Rick O.
http://weblog.techno-weenie.net
http://mephistoblog.com
Rick O. wrote:
And really, how often does your app change things around?
That’s the whole point of agile development - make it easy to change.
If things don’t change, we really don’t need a lot of the magic Rails
delivers.
But yes, ARes was dreamt up before being used in a site.
Okay, here’s my challenge:
Take any actively developed Rails based app that’s more than a year old.
Typo will do, I believe. Check out the src from a year ago, and make
any useful ActiveResource based API. It can do anything useful.
Make a simple client to use it. (The client can’t depend on any of the
app’s source. Best is to write it in a different language - that’s what
Web Services are for.)
Now, update to the latest src. Did the client break? If it does, than
ActiveResource isn’t very useful.
Again, I’m writing because I’m proud of what Rails has done. I feel that
after such success, there’s a move to get into second system syndrome
and out design the world. Rails’ success is based on extraction. Let’s
not loose that.
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
http://rimantas.com/
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.
–
Rick O.
http://weblog.techno-weenie.net
http://mephistoblog.com
On 12/25/06, Robert J. [email protected] wrote:
- Etc.
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
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
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.
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
On Dec 26, 2006, at 9:52 AM, S. Robert J. wrote:
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? 
–
– Tom M., CTO
– Engine Y., Ruby on Rails Hosting
– Reliability, Ease of Use, Scalability
– (866) 518-YARD (9273)
(I’ll end my comments by pointing out that I think Rails is great. I
hope my constructive criticism is received in the spirit it’s intended.)
A second note on this. This is a false declaration of content. Like if
I picked up a jar that said it contained sugar, but was full of
vinegar. The label does not make the content sweet, regardless of the
font size used.
If you wish to provide “constructive criticism” then I’d recommend
using a less flashy banner (“Why ActiveResource will flop…”) and
replace hasty conclusions with invitations to debate. That way you
don’t even need a disclaimer saying that your vinegar is really sugar.
The taste will make that self-evident.
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.
On 27/12/2006, at 7:13 AM, DHH wrote:
If you wish to provide “constructive criticism” then I’d recommend
using a less flashy banner (“Why ActiveResource will flop…”) and
replace hasty conclusions with invitations to debate. That way you
don’t even need a disclaimer saying that your vinegar is really sugar.
The taste will make that self-evident.
That’s the biggest thing I’ve got out of this thread. Nice one.
On 12/26/06, S. Robert J. [email protected] wrote:
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.
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
Ouch. I appreciate that the point is well meant David, but it comes
across a little harsh.
The programmer community is not known for its articulation, and most do
not have your skills in that area (and without question a lot of other
areas as well).
Isn’t it encumbent upon those ‘in the know’ to re-read hasty
conclusions and inflammatory subject lines as invitations to debate -
particularly if there is any semblence of an ‘attack’ on Rails Core
developers?
Otherwise the mildly inarticulate acolyte will feel crushed by the
tutting and wagging of fingers of those they revere. And then they are
lost to the debate and our community is poorer for it.
NeilW