On 02/22/2013 02:53 PM, Dan Callaghan wrote:
Excerpts from Nick Coghlan's message of 2013-02-22 14:03:29
+1000:
> On 02/22/2013 01:31 PM, Nick Coghlan wrote:
>> You *could* just use the bare URLs instead of moving them inside a
>> namespace like that, but it gives you a lot more freedom to create
>> self-describing data if you don't.
>
> To make this a little less abstract...
[...]
>
> If you insist on using a stateful non-self-describing design instead,
> then I *will* ask you to use a "/v1/" prefix as Bill suggested.
Okay this is far more than I think we should add in the first version of
the API, because:
* it goes way beyond the goal of defining the "bare minimum" API needed
for a harness implementation (I may have left that phrase out of the
design proposal, but it was my original intention)
* it is a fair bit of work writing the code to produce all this
* designing JSON representations is apparently contentious, and a lot of
work
So what I will add to the propsal is just: GET for the log files
themselves, and GET for the logs/ and remote-logs/ collections returning
an HTML index or an Atom feed.
Atom has a distinct content type (application/atom+xml) so that doesn't
preclude us from adding this style of JSON and XML representations later
on.
Sounds good to me. Perhaps add something to Deferred Features?
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)