将处理控制映射到 REST

Question

假设您有一个管理长时间运行的（自动）进程的服务。可以启动、暂停、恢复或取消进程。例如，考虑视频转换或 3D 打印。所有以前运行和当前正在运行的进程的列表始终可用。

我正在尝试将此概念映射到 REST 并遇到一些问题。

开始可能会映射到POST /processes，但感觉很奇怪。开始不是创建，并且POST意味着为某些集合创建项目，而为其他集合启动过程听起来令人困惑。但这部分就不那么重要了。

暂停，恢复和取消是我绊倒的地方。我可能会将其视为PATCH - 但是RESTful和RPC方法之间有什么区别呢？

但是，对于 PATCH，封闭的实体包含一组 描述当前驻留在 应修改源服务器以生成新版本。

如果指令指定状态应设置为暂停，这似乎会破坏封装并感觉任意 - 暂停可能影响的不仅仅是状态（任何内部任务等）。

如果指令实际上是pause的 — 这样更好，但如果所有客户端都必须知道这些特定的消息，那么与 RPC 相比有什么好处呢？

Answer 1

POST到集合资源/processes创建默认状态下的新进程。响应包含标头

Location: /processes/42

此过程的状态可以通过以下方式检索

GET /processes/42

这可能是

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

如果客户端想要更改此过程的状态，他可以

POST /process/42
{
  "state": "started"
}

请注意，JSON 不完整。此模式通常用于对现有资源的POST请求，可以解释为"使用提供的参数更新资源"。当然，服务器可以自由地忽略此请求，因为服务器状态会损坏或由于其他原因。

REST 是关于资源及其表示的。REST 客户端的客户端状态可能与服务器状态不匹配。并非客户端请求的服务器状态的每个转换都是可行的。