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?