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
