8 An API for the manager

In chapter 7, we implemented the core functionality of the manager component: pulling tasks off its queue, selecting a worker to run those tasks, sending them to the selected workers, and periodically updating the state of tasks. That functionality is just the foundation and doesn’t provide a simple way for users to interact with the manager.

So, like we did with the worker in chapter 5, we’re going to build an API for the manager. This API wraps the manager’s core functionality and exposes it to users. In the case of the manager, users means end users, that is, developers who want to run their application in our orchestration system.

The manager’s API, like the worker’s, will be simple. It will provide the means for users to perform these basic operations:

This API will be constructed using the same components used for the worker’s API. It will comprise handlers, routes, and a mux.

8.1 Overview of the manager API

Before we get too far into our code, let’s zoom out for a minute and take a more holistic view of where we’re going. We’ve been focusing pretty tightly for the last couple of chapters, so it will be a good reminder to see how the technical details fit together.

8.2 Routes

8.3 Data format, requests, and responses

8.4 The API struct

8.5 Handling requests

8.6 Serving the API

8.7 A few refactorings to make our lives easier

8.8 Putting it all together