[Ovirt-devel] OVirt public API

[Michael DeHaan]

David Lutterkort wrote:
> 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.
>   
Hopefully.  In this case we see something standard like the XMLRPC spec 
over HTTP
get/post/etc.  This is what it needs.    Maybe call this "RESTX" or 
substitute in some name
that does not suck :)

> 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.
>   

Hmm, good deal.

I would advise against YAML.  It's fine if you control the library, but 
there's a big mix of 1.0/2.0 out there
and they don't play nicely.

JSON is nice in that it has only one real "version" (maybe they'll screw 
that up) and also plays nicer for AJAXy
things for those that care about that.

> 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.
>   
Indeed.  XMLRPC is obviously not a good way to do large file requests, 
sure enough.    Luke was using
that wrong.  That being said, it holds up quite fine for things like 
Satellite AFAIK, especially if you
turn on the threading/forking mixins.

Anyhow, in this case, the concern is not as much for people writing 
enterprisey software, but the sysadmins
who want to write tools to automate their ovirt infrastructure.   If we 
provide them nice libraries that wrap the ugly XML
parsing bits, and show them how to do things in a minimalistic way, 
that's ok... we just have to have that. 

Flickr's REST support is an example of how to do that wrong, seeing they 
didn't put out those libraries and the open source
ones out there are pretty bad as they had to reverse engineer the API or 
sorts to get all the bits working, where something like
XMLRPC would have mostly just worked out of the box.   Anyhow, as long 
as you can keep admins away from XML and
keep their code short, they will be reasonably happy.

--Michael



> David
>
>
>