Let's Build an API together - Part 1

Last Update: 13.12.2017. By Jens in API Series | APIs | Newsletter

In the center of Kanban is the so-called Kanban Board; yes, it is an actual board. On it, there are usually 3 columns, called swim lanes. The lanes represent the state of a task and are named Ready, Doing and Done; starting on the left. Each individual todo aka task is written on a post-it note and depending on its state, put in a column. Usually, a task will start on the left in Ready.

Now the job is to work on these tasks and move them from left to right until they are done. The only rule is, the number of tasks in the Doing lane is limited. For single-user aka personal Kanban, it is a good to start with a 2 or 3 items limit. So, at no time you should have more than 3 items in the doing lane. It will slow down your progress. The goal of the whole system is to get your task as fast as possible from to done state.

The benefit of this system is, it is dead simple, and you have a visual representation of all tasks. You see exactly where a particular task is in the flow.

The first version of our Kanban API will start with the bare minimum of one board, three lanes and 3 categories for the tasks. A category is just an arbitrary classification like work task, personal task, household, etc. In a classic offline version you’d use colored post-its for that, and each category has its own color.

Assume we already did a discovery phase covering why and what the client actually wants from a business perspective and let’s focus on the tech side.

The first thing we should always do is to create a text file for logging our design decisions with date and assumptions, findings, etc. Why?

Because you do them conscious now and can later look up why you did X in Y way. Trust me, you will not remember 6 months from now, why you made a particular design decision.

Now, we can start with a couple of questions:

• Who’s the client of the API?
• How can they interact with the API technically like communication over HTTP, JSON, XML?
• How does the client use the API from a functional perspective? How do they do a particular task like moving a task across the board?

Of course, by answering them, new questions arise. So let’s see what my client, me, wants. You can follow along with my assumptions, but I encourage you to make your own and stray away :-)

The API will have only one client, and it is a single page application written in Javascript and will run in the browsers. However, there might be other clients later, but we assume they all can use the same communication techs.

As the client is a browser, we will be using HTTP, and as we are not bound by any legacy model, we use JSON.

The client will be able to create and delete individual tasks. It moves the task around by changing a property of the task. This property defines the lane the task is in.