11 Rerunnable jobs

 

This chapter covers

  • What rerunnable jobs are
  • How rerunnable jobs differ from long-running operations
  • How to represent rerunnable jobs as resources
  • The benefits of supporting rerunnable jobs over custom methods returning LROs
  • How to represent job results with job execution resources

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 10, 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 trigger the invocation somewhere by calling the API method. This works fine for methods that are only ever intended to run on demand, but there are three scenarios worth considering that aren’t quite solved by simply having a method that returns an LRO.

11.2 Overview

11.3 Implementation

11.3.1 Job resources

11.3.2 The custom run method

11.3.3 Job execution resources

11.3.4 Final API definition

11.4 Trade-offs

11.5 Exercises

Summary