In the API community, we often hear about the “API lifecycle”.
There are different variations around this concept, but it relates to the various stages and activities an API project goes through: design, development, documentation, testing, deployment, consumption, management, monitoring, promotion, versioning, retirement, etc.
You’ll find cycles more design focused on the design / development / testing / production aspects, and others more management focused with development / integration / management / monitoring.
The idea behind those cycles is that it’s a turning wheel, a virtuous cycle your API goes through, almost unalterably. But my personal feeling is that it’s way more malleable and permeable than this circle, as you can shortcut through stages, reach other steps with different transitions, in a much more complex graph than a mere cycle.
For me, it’s an API flow!
And interestingly, just days ago, I see this sentiment echoed by Zdenek Nemec, the director of DSL development at Apiary, commenting on Twitter:
“API Flow. Because you do not have to run in cycles” — @zdne
And indeed, to add depth to this statement, Zdenek illustrates the flow with a picture of a whiteboard, outlining the phases: preparation, design & prototype, develop, deliver, consume, and gather & analyse feedback.
Zdenek then turned his whiteboard drawing in a nicer picture of his “API Design Flow”:
There’s not just one flow, but many flows, depending on the viewing angle you’re taking, or whether you have a particular focus on design, or management.
The life of an API is not to turn in circles forever, but it’s a more complex state diagram, a workflow, with many possible transitions from one stage to another. Whether you represent it linearly, with some loopbacks, or around a circle, working on Web APIs is a really rich and diverse experience which makes you go from a particular state to another state with more transitions than letting the circle go round and round forever.
Let’s get into the (API) flow!