Hi Mark,
Thanks for this link, interesting.
So it seems that RHEV-M does already provide an XML Schema (XSD). Which is the approach I
was trying to promote for our APIs. Creating this could be part of the CLI effort?
Quote:
"The creation of the class hierarchy is tremendously more simple if an XMLSchema code
generator is avalailable for your language/platform. This is because the RHEV API
itself provides an XMLSchema file that defines all the objects. This file can be used with
a code generator to generate the classes automatically. The Python bindings use the
"PyXB" schema generator for example. "
Also, (whilst we're here) another opinion of mine is that choosing a REST API over
than say SOAP (given it's advantages) results in one issue, which is that there is no
standard way to formally define it, compared to say a WSDL, and in my experience I've
found provided documentation insufficient. So, I think it might also be worth a bit of
effort, trying to really pin down the API as much as possible and do a good job
documenting the APIs as much as possible, not just supplying examples.
Cheers
Martyn
----- Original Message -----
From: "Mark McLoughlin" <markmc(a)redhat.com>
To: "Martyn Taylor" <mtaylor(a)redhat.com>
Cc: gjansen(a)redhat.com, aeolus-devel(a)fedorahosted.org
Sent: Tuesday, 7 June, 2011 2:56:21 PM
Subject: Re: CLI - Formal XML Definition
Hi Martyn,
On Tue, 2011-06-07 at 06:45 -0400, Martyn Taylor wrote:
Providing a formal deffinition of the XML for an API, makes using
the
API, in particular creating and maintaining client applications that
utilise the API much simpler, and far clearer for a developer.
There are an array of tools that provide class generation, and
automatic marshalling and unmarshalling of objects, generated straight
from a formally defined XML Document, for ruby, this project looks to
offer these functions:
https://github.com/rubyjedi/soap4r .
In my experience writing Java and Android clients, I have found that
the time spent creating an XSD or other formal XML definition, repays
10 fold in development time, and also makes keeping clients up to date
alot simpler. For DC Client I ended up writing my own:
https://github.com/mtaylor/deltacloud-tools/blob/master/DeltaCloudClient/...
But, I think it would be better as a whole to adopt this approach from
the start. It would not only benefit the creation of the CLI but also
anyone else who needs to utilise these APIs
It might be good to compare your approach to the one taken by the
rhevm-api project. Indeed, only today, Geert wrote up some nice info on
how to write client bindings for the API using our schema:
https://fedorahosted.org/pipermail/rhevm-api/2011-June/002358.html
https://fedorahosted.org/rhevm-api/wiki/ClientBindings
Cheers,
Mark.
_______________________________________________
aeolus-devel mailing list
aeolus-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/aeolus-devel