[Ovirt-devel] OVirt public API

[David Lutterkort]

On Wed, 2008-07-16 at 16:09 -0400, Michael DeHaan wrote:
> Michael DeHaan wrote:
> > 
> > I would make an argument for XMLRPC/SSL based on that a lot of our 
> > management applications already have XMLRPC API's (such as 
> > Spacewalk/Cobbler/etc), and that serialization and more remote faults 
> > are supported.   Having an app have to speak to multiple API types if 
> > of course going to be a reality.
> >
> > That being said, REST is definitely workable, and as long as there is 
> > an API, I think most people will be reasonably happy.
> >
> > Basically with XMLRPC you don't have to write any wrapper code around 
> > the API caller and it just works as if it were a local API, which is  
> > nice
> >
> I should add, embedding XML in an XMLRPC request as a string sounds 
> weird, but does work.   The main benefit is not the format, which is not 
> perfect, just that there are a lot of nice libraries that make XMLRPC 
> behave as if it were a local API/module, doing the usual 
> getattr()/method_missing magic and so forth.

This seems to come down to an argument that
serialization/deserialization, or in general, support for XMLRPC, is
more mature than for REST - I don't doubt that that's true right now,
simply because XMLRPC has been around for much longer.

With all the attention that REST has been getting, and Rails shunning
SOAP/XMLRPC etc. explicitly in favor of rest, it's only a matter of time
before REST support in other languages catches up with that for XMLRPC.

In the meantime, there are things like pyActiveResource which seems a
good start for Pyhton, and alternatively, using well-supported
serialization formats like YAML or JSON.

One of the things that makes me very hesitant about XMLRPC is that I've
been watching it fall apart in the case of puppet - Luke is still trying
to dig out from under that decision, and migrating away from it.

David