stanbol-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Enrico Daga <enricod...@gmail.com>
Subject Reasoners jobs REST interface
Date Fri, 18 Nov 2011 14:45:50 GMT
Hi,
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.

The process could be the following:

1) /reasoners/<service>/<task>/job
A client send a request to a reasoning service, asking to execute it
as a background job, for example:

curl http://localhost:8080/reasoners/owl/classify/job?url=<url to classify>

This service will return:
- 302 Found. Job have been started. This will contain the HTTP header
"Location: http://localhost:8080/reasoners/jobs/ping/JWUIiSjqZUtzmwCRqGgqeA"
(last part is the job identifier) -> 2)
- 400, 404, 500 (depends on the kind of error)

2) /reasoners/jobs/ping/<job id>
The client goes to the ping service, which returns:
- 204 No content. Job is still running, result is not ready to be consumed.
- 302 Found. Job have been completed. This will contain HTTP header
"Location: http://localhost:8080/reasoners/jobs/get/JWUIiSjqZUtzmwCRqGgqeA"
-> 3)
- 404 Job do not exists.
- 500 Some error occurred.

3) /reasoners/jobs/get/<job id>
The client goes to the get service, which behaves the same as GET/POST
on real time requests (supports accept header, but POST+multipart here
is not allowed) to obtain the response:
- 200 OK. Process completed correctly, the content is consistent and
if some content is produced it comes back to the client (task
'classify' or 'enrich')
- 204 No content. Process completed correctly but data is not consistent
- 404 The job does not exists or is not ready
- 500 Some error occurred

I am not sure what will happen next. The background process, even
complete, remains in memory and can be queried through the /get
service more then 1 time. This could be handy, but some way of
removing a completed job must exists. We could:
1) Delete the job when a first call to /get 200|204 is done
2) Prepare a service /clean/<job id> and /clean-all/ services for
removal (I am for this option)
(in the future we may want to support both ways, through configuration)

Another aspect is job interruption. We could setup a service /stop and
/stop-all to force job stopping and cleaning.

If anybody have some feedback about this design I am happy to discuss.

Enrico


-- 
Enrico Daga

--
http://www.enridaga.net
skype: enri-pan

Mime
View raw message