Hi there,
I just ran into a problem related to active resource and incompatibility between 1.2.3 and edge.
The problem is related to my REST source (rails 1.2.3) generating xml that looks like this:
<people> <person><id type="integer">1</id><first>Ryan</first></person> <person><id type="integer">2</id><first>Jim</first></person> </people>
Whereas active resource (edge) expects it like this (from AR docs):
Collections can also be requested in a similar fashion
# Expects a response of
I just ran into a problem related to active resource and incompatibility between 1.2.3 and edge.
Well, ActiveResource is still an unreleased library. It will get its first official release sometime soon with Rails 2.0. But I see your point about trying to be compatible with older Rails applications that don't use the new array marshaling code.
The problem is related to my REST source (rails 1.2.3) generating xml that looks like this:
<people> <person><id type="integer">1</id><first>Ryan</first></person> <person><id type="integer">2</id><first>Jim</first></person> </people>
Whereas active resource (edge) expects it like this (from AR docs):
Collections can also be requested in a similar fashion
# Expects a response of # # <people type="array"> # <person><id type="integer">1</id><first>Ryan</first></person> # <person><id type="integer">2</id><first>Jim</first></person> # </people> # # for GET http://api.people.com:3000/people.xml #
I believe it would make sense to write a few lines of code in xml_format.rb that handles this (basically figuring out that because there is more than one direct child element called person, it should consider it an array).
That's how things used to work, but it was unreliable and couldn't deal with arrays containing zero or one elements. I'm the author of the patch that added the type="array" attribute, and I did think about how to deal with the backward compatibility. I just couldn't figure out how to do it reliably (which was the whole problem with that approach in the first place), so I punted.
One other thing I'd like to bring up is that I think it would make sense to make the XML format more flexible, letting people write their own marshallers/unmarshallers on a per model basis; That way it would be quite easy to integrate with systems that are not rails based. I believe this would make AR more successful.
From what I've heard, ActiveResource and the ActiveRecord xml code is meant more for closely coupled client/server interaction than building a generic public XML API, but that's just hearsay and could be wrong. However, if you want Rails to interoperate with other systems, it's probably time to think about embracing an existing standard. I don't know of any widely adopted RESTful XML API standards. Do you?
That's how things used to work, but it was unreliable and couldn't deal with arrays containing zero or one elements. I'm the author of the patch that added the type="array" attribute, and I did think about how to deal with the backward compatibility. I just couldn't figure out how to do it reliably (which was the whole problem with that approach in the first place), so I punted.
Ok, I didn't think of that.
From what I've heard, ActiveResource and the ActiveRecord xml code is meant more for closely coupled client/server interaction than building a generic public XML API, but that's just hearsay and could be wrong.
Well, I thought REST in it's nature was supposed to be loosely coupled, but I might be wrong too...
However, if you want Rails to interoperate with other systems, it's probably time to think about embracing an existing standard. I don't know of any widely adopted RESTful XML API standards. Do you?
Not really, and I see this as one of the major problems with REST these days. Axis2 provides REST support - maybe we should look at their stuff?
The XML-RPC guys created a spec a few years ago that tried solving similar issues by defining a spec: http://www.xmlrpc.com/spec Maybe the rails way should become the standard? In that case it would make sense to create implementations in other languages as well.
Cheers,
Stefan