Hi Enrico, On Fri, Nov 18, 2011 at 3:45 PM, Enrico Daga <[email protected]> wrote: >... I am working on STANBOL-343 (Long term operations (Jobs) for reasoning > services). The background work is almost complete, now I am going to > better define the interface of the /reasoners/jobs service....
I would do it differently, I think the API below is simpler and I'm intentionally using content to describe the details of the job status instead of "abusing" HTTP status codes: 1) Create a job POST to /reasoners/owl/classify or any suitable path that can create jobs. With input that describes what to classify returns 201 created with Location header pointing to the job (say /jobs/1234) and HTML content that contains <a rel="job" href="/jobs/1234"> (or JSON equivalent if that's useful) 2) Watch for job completion GET /jobs/1234 Returns 200 if the job exists Body describes the job status, in JSON or HTML Body contains a link to the job output, for example /jobs/1234/output.txt Body contains a comment that mentions the DELETE method described in 4) 3) Read job output GET to the path returned in 2), /jobs/1234/output.txt in this example. Might return 404 as long as the job is not finished, with HTML or JSON content that points to the parent job resource, /jobs/1234. 4) Cleanup or interrupt jobs DELETE /jobs/1234 or DELETE /jobs for all jobs If a job was running, this requests its termination, and the resource disappears once terminated. This should let you create and watch jobs from a browser, while being machine-friendly. The /jobs path should be handled by a generic component for long-running jobs, decoupled from the reasoners. WDYT? -Bertrand
