[Ovirt-devel] OVirt public API

[Michael DeHaan]

David Lutterkort wrote:
> On Wed, 2008-07-16 at 16:07 -0400, Michael DeHaan wrote:
>   
>> I would make an argument for XMLRPC/SSL based on that a lot of our
>>     
>
> OVirt uses Kerberos for authentication/authorization throughout, and I
> was not planning onchanging that for the API. To do authorization with
> SSL we'd have to get into the business of distributing client-side
> certs, and I would only want to make that move if that is done for OVirt
> as a whole (which, from what I understand, wouldn't happen unless
> FreeIPA supports it).
>   

Right.   I was referring to data stream encryption, not authn/authz.

>> management applications already have XMLRPC API's (such as 
>> Spacewalk/Cobbler/etc), and that serialization and more remote faults 
>> are supported.
>>     
>
> All I can find about XMLRPC faults is that there's a certain XML format
> for faults which transmits an integer error code and a string error
> message, with no agreement on what those integer codes mean - the
> response is actually sent back with an HTTP status 200 (okiedokie). I'd
> argue that situation is worse than for REST, where errors are reported
> both through the HTTP status (like 403 - go log in) and the payload.
> That has the advantage that HTTP status codes are fairly extensive and
> have well defined meanings.
>   

The main nice thing is the libraries are usually smart enough to 
translate them automatically
to caller-side exceptions and raise something (forcing the caller to 
deal with them), but yes,
the data you get from that is limited.   

> David
>
>
>