RESTful Job Assignment

I have a collection of jobs that need processing, http://example.com/jobs. Each job has a status of "new", "assigned" or "finished".

I want slave processes to pick off one "new" job, set it's status to "assigned", and then process it. I want to ensure each job is only processed by a single slave.

I considered having开发者_开发百科 each slave do the following:

1. GET http://example.com/jobs
2. Pick one that's "new" and do an http PUT to http://example.com/jobs/123 {"status=assigned"}.
3. Repeat

The problem is that another slave may have assigned the job to itself between the GET and PUT. I could have the second PUT return a 409 (conflict), which would signal the second slave to try a different job.

Am I on the right track, or should I do this differently?

I would have one process that picks "new" jobs and assigns them. Other processes would independently go in and look to see if they've been assigned a job. You'd have to have some way to identify which process a job is assigned to, so some kind of slave process id would be called for.

(You could use POST too, as what you're trying to do shouldn't be idempotent anyway).

You could give each of your clients a unique ID (possibly a UUID) and have an "assignee/worker" field in your job resource.

1. GET http://example.com/jobs/
2. POST { "worker"=$myID } to http://example.com/jobs/123
3. GET http://example.com/jobs/123 and check that the worker ID is that of the client

You could combine this with conditional requests too.

On top of this, you could have a time out feature if the job queue doesn't hear back from a given client, it puts it back in the queue.

It looks that the statuses are an essential part of your job-domain model. So I would expose this as dedicated sub-resources

# 'idle' is what you called 'new'
GET /jobs/idle
GET /jobs/assigned

# start job
PUT /jobs/assigned/123

Slave is only allowed to gather jobs by GET /jobs/idle. This never includes jobs which are running. Still there could be race conditions (two slaves are getting the set, before one them has started job). I think 400 Bad Request or your mentioned 409 Conflict are alright with that.

I prefer above resource-structure instead of working with payloads (which often looks more "procedural" to me).

I was a little to specific, I don't actually care that the slave gets to pick the job, just that it gets a unique one.

With that in mind, I think @manuel aldana was on the right track, but I've made a few modifications.

I'll keep the /jobs resource, but also expose a /jobs/assigned resource. A single job may exist in both collections.

The slave can POST to /jobs/assigned with no parameters. The server will choose one "new" job, move it to "assigned", and return the url (/jobs/assigned/{jobid} or /jobs/{jobid}) in the Location header with a 201 status.

When the slave finishes the job, it will PUT to /jobs/{jobid} (status=finished).