rest - タスクキューの残りの設計

Question

タスクキューの残りのインターフェイスを設計しており、ベストプラクティスについて疑問に思っています。

1 つのアクションは、キュー内の「次の」タスクを受け入れることです。

ジョブを受け入れると、最初のワーカーのみがジョブを取得します。

ワーカーは、ジョブを受け入れるまで、タスクまたはタスク ID を知りません。

GET はべき等ではないため、使用できないと考えています。nextTask を 2 回呼び出すと、2 つの異なるジョブが取得されます。だから私はそれがPOSTであるべきだと思います。

POST //rest/taskqueue?action=acceptTask

それとも、私はそれを間違った方法で見ていますか？

score 5 · Accepted Answer

基本的：

これは私がそれを行う方法です。

新しいタスクをキューに入れます。

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

特定の ID を持つ新しいタスクをキューに入れます。

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

最も古いタスクを取得します。

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

キューが空の場合:

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

特定のタスクをデキューします。

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

タスクがすでに処理されている場合...

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

最も古いアイテムを直接デキューする場合...

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

score 0 · Accepted Answer

POST は「追加」動詞であり、HTTP 仕様による「データ処理」動詞でもあります。したがって、概念的には、処理のためにタスクをタスクリストに追加します。POSTはちょうどいいです。

GET が正しくないもう 1 つの理由は、GET がリソースを変更することを想定していないためです。しかし、着信要求は変更を加えようとしています... 1 つの項目が追加されます。

「action=acceptTask」は省略します。REST では、HTTP 動詞がインテントを指定し、URI がターゲットを指定します。あなたがしているのは、新しいタスクをキューに追加することです...「アクション」パラメーターは何も追加しません。

通常、リクエストに追加情報を提供する場合は、パラメーターを追加して、何をすべきかに関する修飾子を提供できます。しかし、もう 1 つの規則は、多かれ少なかれごまかして、意図を URI の最後に置き、それをサブリソースとして (つまり、パラメーターではなく) 扱うことです。例えば：

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...)

ただし、HTTP 動詞を複製することは絶対にしないでください。これは、基になるプロトコルの誤用であり、REST では禁止されています。

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

rest - タスク キューの残りの設計