5 An API for the worker

 

This chapter covers

  • Understanding the purpose of the worker API
  • Implementing methods to handle API requests
  • Creating a server to listen for API requests
  • Starting, stopping, and listing tasks via the API

In chapter 4, we implemented the core features of the worker: pulling tasks off its queue and then starting or stopping them. Those core features alone, however, do not make the worker complete. We need a way to expose those core features so a manager, which will be the exclusive user, running on a different machine can make use of them. To do this, we’re going to wrap the worker’s core functionality in an application programming interface, or API.

The API will be simple, as you can see in figure 5.1, providing the means for a manager to perform these basic operations:

  • Send a task to the worker (which results in the worker starting the task as a container)
  • Get a list of the worker’s tasks
  • Stop a running task
Figure 5.1 The API for our orchestrator provides a simple interface to the worker.
05-01

5.1 Overview of the worker API

We’ve enumerated the operations that the worker’s API will support: sending a task to a worker to be started, getting a list of tasks, and stopping a task. But how will we implement those operations? We’re going to implement those operations using a web API. This choice means that the worker’s API can be exposed across a network and that it will use the HTTP protocol. Like most web APIs, the worker’s API will use three primary components:

5.2 Data format, requests, and responses

5.3 The API struct

5.4 Handling requests

5.5 Serving the API

5.6 Putting it all together

Summary

sitemap