Geek Answers Handbook

Rest Design for task queue

I am developing a queue waiting interface and wondering about best practice.

One action is to accept the “next” task in the queue.

Having accepted the task, only the first employee will receive the task.

The employee will not know the task or task identifier until it accepts the task.

Now I think I can’t use GET because it’s not idempotent. If you call nextTask twice, you get two different jobs. Therefore, I assume that this should be a POST.

POST // rest / taskqueue? action = acceptTask

Or am I looking at it wrong?

+4
source share
3 answers

Basically:

  • GET - reads data without changing the resource (idempotent). You can do as many GETs as you want, it will never change the resource.
  • PUT - direct placement of data in a resource (not idempotent)
  • POST - adds data to the resource (not idempotent)
  • DELETE - removes data from a resource (not idempotent)

This is how I do it.

Define a new task:

--> POST http://api.crazyjoes.com/v1/tasks/ --> {"data":{"lulcat":true}} <-- 202 Accepted

Complete a new task with a specific identifier:

 --> PUT http://api.crazyjoes.com/v1/tasks/393ee7f6-c44a-4b34-86ac-92c9f31a4bc6/ --> {"data":{"lulcat":true}} <-- 202 Accepted

Get the old task:

 --> GET http://api.crazyjoes.com/v1/tasks/oldest/ <-- 200 OK <-- {"id":123,"data":{"lulcat":true}}

If the queue is empty:

 --> GET http://api.crazyjoes.com/v1/tasks/oldest/ <-- 204 No Content

Cancel the specific task:

 --> DELETE http://api.crazyjoes.com/v1/tasks/123/ <-- 200 OK <-- {"id":123,"data":{"lulcat":true}}

If the task has already been processed ...

 --> DELETE http://api.crazyjoes.com/v1/tasks/123/ <-- 410 Gone

If you want to delete the oldest item right away ...

 --> DELETE http://api.crazyjoes.com/v1/tasks/oldest/ <-- 200 OK <-- {"id":123,"data":{"lulcat":true}}
+2
source

What about:

/tasks and /tasks/{taskId} are the usual set of all tasks and a single task, respectively.

/tasksqueue are the tasks in the queue, and /tasksqueue/top is the top of the queue and only supports GET. Suppose all tasks have a unique identifier.

Then issue GET /tasksqueue/top to get the task identifier at the top of the queue, and issue DELETE /tasksqueue/{taskId} to try to jump out of the queue.

If this fails, that is, returns a non-20x, it means that someone else has jumped into the queue between your calls.

If this succeeds, it will return the task to its body, and you can do what you want with it, knowing that you successfully pulled it out. Or, since you know your identifier, you can get task information from /tasks/{taskId} .

He must not succeed more than once.

And you can issue DELETE /tasksqueue/{taskId} several times with the same overall effect on the system as one of them, so DELETE acts idempotently as it should. (The fact that all or all but the first DELETE calls return non-20x does not change this fact.)

+1
source

POST is an "additional" verb, as well as the verb "data processing" according to the HTTP specification. So, conceptually, you add a task to the list of tasks for processing. POST is fine.

Another reason that the GET is incorrect is because the GET should not make changes to the resource. But the incoming request is about to make a change ... it will add one element.

I would leave "action = acceptTask". In REST, an HTTP verb indicates your intention, and a URI indicates the goal. So what you do is add a new task to the queue ... the action parameter does not add anything.

Typically, if you want to provide additional information for a query, you can add parameters to provide modifiers about what to do. But another convention is to more or less deceive and put intent at the end of the URI and treat it as a sub-resource (that is, instead of a parameter). eg:.

 ht_p://.../taskqueue/fold ht_p://.../taskqueue/roll ht_p://.../taskqueue/rattle (hm. not sure how many things you can actually do with a queue...)

However, you should never duplicate HTTP verbs ... what is the misuse of the underlying protocol and no-no in REST:

 ht_p://.../taskqueue/get ht_p://.../taskqueue/update ht_p://.../taskqueue/delete ...ack!
0
source

More articles:


All Articles