On 02/22/2013 12:54 PM, Dan Callaghan wrote:
Excerpts from Dan Callaghan's message of 2013-02-22 12:51:31
+1000:
> Excerpts from Nick Coghlan's message of 2013-02-22 12:25:03 +1000:
>> I was actually going to ask about that - is there any reason not to
>> have GET counterparts for most of the URLs in the API? It would be
>> nice not to have to go through the main XML-RPC API in order to read
>> back results when testing a harness.
>
> The recipe XML gives back everything that you can create or modify
> (status, results, logs, ...) so you can just use that.
Actually that's not true, it doesn't give back the complete logs
(obviously) but it does not even give back a *listing* of which logs
exist. There is a separate XML-RPC interface for that.
So yes, I will definitely add GET for fetching all the stuff back.
On that note, what are people's preferred ways of returning a listing of
resources (e.g. GET /recipe/1234/logs/)? HTML, Atom, JSON array of
hrefs, ...?
For PulpDist, I used djangorestframework's content negotiation to
publish human readable HTML, XML and JSON. I don't think we need to go
that far - basic structured data as JSON files should suffice (and is
the REST tradition).
While I don't agree with all the details, my general philosophical guide
for RESTy APIs is this article written by one of the RHEV developers:
https://restful-api-design.readthedocs.org/en/latest/
Alas, I don't have a public example of what I did for PulpDist to share
with you, but I'll send you an RH internal one.
Cheers,
Nick.
--
Nick Coghlan
Red Hat Infrastructure Engineering & Development, Brisbane
Python Applications Team Lead
Beaker Development Lead (
http://beaker-project.org/)
PulpDist Development Lead (
http://pulpdist.readthedocs.org)