11 Rerunnable jobs
There are many cases where an API needs to expose some customizable functionality that runs repeatedly, however we don't always want to be required to provide all the details for that functionality each time it needs to be run. Further, we may want the ability to execute this chunk of configurable work on a schedule that is owned and maintained by the API server rather than invoked by the client. In this pattern, we explore a standard for defining specific units of work that are configurable and rerunnable, potentially by users with different levels of access in the API. We also provide a pattern for storing the output of each of these executions.
11.1 Motivation
As we learned in Chapter 13 (Long-running operations), sometimes we'll come across methods in an API that cannot, or should not, return immediately. Having the ability to handle asynchronous execution is clearly very valuable, however it still requires that a client somewhere trigger the invocation by calling the API method. This works fine for methods that are only ever intended to run "on-demand", however there three scenarios worth considering that aren't quite solved by simply having a method that returns a long-running operation.