On 12/19/2012 11:50 PM, Dan Callaghan wrote:
First sketch of an HTTP API below. I don't think I've forgotten 

Hi Dan,

What if a group wants to use an alternate harness?  Is the idea that the alternate harness provide a backend plugin which would use this API?  or would we be free to communicate directly back to a different results server? 

Excerpts from Dan Callaghan's message of 2012-12-19 16:46:19 +1000:
There are four areas the API needs to cover (that I can think of). The 
harness needs to be able to:

* find out what to run
Get recipe XML:

    GET /recipes/{recipeid}
    Accept: application/xml

* report results and upload logs
Record a task result:

    POST /recipes/{recipeid}/tasks/{taskid}/results/
    Content-type: application/x-www-form-urlencoded


->  302 See Other
    Location: /recipes/{recipeid}/tasks/{taskid}/results/{resultid}

Upload recipe log:

    PUT /recipes/{recipeid}/logs/{path...}

Upload task log:

    PUT /recipes/{recipeid}/tasks/{taskid}/logs/{path...}

Upload task-result log:

    PUT /recipes/{recipeid}/tasks/{taskid}/results/{resultid}/logs/{path...}

These could accept Content-Range (for partial uploads) and Content-Type 
(which we could store and return later).

* extend the watchdog time
Set watchdog to now + X seconds:

    POST /recipes/{recipeid}/watchdog
    Content-type: application/x-www-form-urlencoded


* synchronize with other recipes in the recipe set
Block until all other recipes in the recipe set (except guest recipes?) 
have called this, or until X seconds have elapsed:

    POST /recipes/{recipeid}/sync-start?timeout=X

Beaker-devel mailing list