Mapping processing control to REST

Question

Let's say you have a service that manages long-running (automatic) processes. Process can be started, paused, resumed or cancelled. As an example, consider video conversion or 3d printing. A list of all previously run and currently running processes is always available.

I am trying to map this concept to REST and having some problems.

Start can potentially be mapped to POST /processes, but it feels weird. Start is not create, and having POST mean create item for some collections, and start process for others sounds confusing. But that part is less important.

Pause, resume and cancel is where I stumble. I could potentially see it as PATCH — but what is the difference between RESTful and RPC approaches then?

With PATCH, however, the enclosed entity contains a set of instructions describing how a resource currently residing on the origin server should be modified to produce a new version.

If the instruction specifies that status should be set to paused, this seems to break encapsulation and feels arbitrary — pause can potentially affect much more than just status (any inner tasks etc).

If the instruction is literally pause — this is better, but what's the benefit over RPC if all clients have to know these specific messages anyway?

Answer 1

POST to a collection resource /processes creates a new process in a default state. The response contains a header

Location: /processes/42

The state of this process can be retrieved by

GET /processes/42

which could be

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

If the client wants to change the state of this process, he could

POST /process/42

{
  "state": "started"
}

Note that the JSON is incomplete. This pattern is often used in a POST request to an existing resource and can be interpreted as 'update the resource with the provided parameters'. Of course the server is free to ignore this request because server state would be corrupted or because of other reasons.

REST is about resources and their representation. The REST client has client state which may not match the server state. And not every transition in server state requested by the client may be doable.