0

長時間実行される (自動) プロセスを管理するサービスがあるとします。プロセスは、開始、一時停止、再開、またはキャンセルできます。例として、ビデオ変換または 3D 印刷を考えてみましょう。以前に実行されたプロセスと現在実行されているすべてのプロセスのリストが常に利用可能です。

この概念を REST にマッピングしようとしていますが、いくつか問題があります。

Start は にマッピングされる可能性がありますがPOST /processes、奇妙に感じます。開始は作成ではなく、POST一部のコレクションのアイテムを作成し、他のコレクションのプロセスを開始することは混乱を招くように聞こえます。しかし、その部分はそれほど重要ではありません。

一時停止、再開、キャンセルは、私がつまずくところです。私は潜在的にそれを次のように見ることができましたPATCH—しかし、RESTful と RPC アプローチの違いは何ですか?

ただし、PATCH を使用すると、囲まれたエンティティには、現在オリジン サーバーに存在するリソースを変更して新しいバージョンを生成する方法を説明する一連の指示が含まれます。

命令がステータスを一時停止に設定する必要があることを指定している場合、これはカプセル化を破るように見え、恣意的に感じます — 一時停止は、ステータスだけでなく (内部タスクなど) に影響を与える可能性があります。

命令が文字どおりの場合pause— これは優れていますが、いずれにせよすべてのクライアントがこれらの特定のメッセージを認識しなければならない場合、RPC に比べてどのような利点があるでしょうか?

4

1 に答える 1

1

POSTコレクション リソース/processesに追加すると、既定の状態で新しいプロセスが作成されます。応答にはヘッダーが含まれています

Location: /processes/42

このプロセスの状態は、

GET /processes/42

可能性があります

{
  "id": 42,
  "state": "created"
}

クライアントがこのプロセスの状態を変更したい場合は、

POST /process/42

{
  "state": "started"
}

JSON は不完全であることに注意してください。このパターンはPOST、既存のリソースへのリクエストでよく使用され、「提供されたパラメーターでリソースを更新する」と解釈できます。もちろん、サーバーの状態が壊れたり、その他の理由により、サーバーはこの要求を自由に無視できます。

REST は、リソースとその表現に関するものです。REST クライアントには、サーバーの状態と一致しない可能性のあるクライアントの状態があります。また、クライアントによって要求されたサーバー状態のすべての遷移が実行可能であるとは限りません。

于 2013-10-26T13:24:35.350 に答える