[Ovirt-devel] OVirt public API

[Michael DeHaan]

Michael DeHaan wrote:
> David Lutterkort wrote:
>> Here is my current thinking around a public API for OVirt. The basic
>> idea is that that API will expose all operations that are available
>> through the WUI, with small adaptations to the fact that it's an API,
>> and not an interactive interface.
>>
>> In particular, the API will (eventually) support the following:
>>
>>   * Lifecycle control for virtual machines
>>     (start/stop/suspend/resume/migrate)
>>
>>   * Management of the various pools, i.e. host, storage and VM pools
>>
>>   * Querying of information about the above; I'd explicitly exclude
>>     performance data from this 'information' - I think that should be
>>     communicated by different means (e.g., collectd)
>>
>> Architecturally, the API will be a remote API over HTTP, using a RESTful
>> style; in a nutshell, that means that clients make calls through HTTP
>> requests, with arguments and results suitably encoded - for GET
>> requests, that simply means ordinary request params, for POST, it's TBD
>> which possible ways to serialize data is preferrable. Obvious candidates
>> are XML, YAML, and JSON; right now, I am leaning towards
>> XML. Stylistically, REST uses URL's to represent objects (or 'nouns')
>> and different HTTP methods to retrieve and/or change those objects
>> ('verbs') You can think of the HTTP methods GET, POST, PUT, DELETE as
>> analogous to the SQL actions select, insert, update, and delete,
>> respectively. Or the show/create/update/delete methods in Rails
>> controllers.
>>
>> Besides being lightweight, a RESTful API is also very attractive because
>> of the support for it in Rails 2 (ActionController::Resources on the
>> server side, and ActiveResource for clients) That support takes away a
>> lot of the headaches around serialization of objects, routing etc.
>>   
>
> 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.

s/more remote faults/remote faults/