Active resource - find(:all) and the array type

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