Do We Deploy, Provide, Publish, or Produce an API?

I think a lot about the words we use in the technology sector. What they mean, and what they don’t mean. One of the stops along the API life cycle I struggle with a lot is about how we describe the process of deploying APIs. I chose to use the word "deploy" about five years ago when it comes to my API research, but I have also dabbled in the usage of other terms to describe what we do at this phase of the API life cycle. I wanted to pause for a moment to rethink this usage, and explore why I use deploy, instead of provide, publish, produce, or other ways of describing the act of making an API available. I’m guessing that the purpose and meaning of the words we use impacts the entire API life cycle in ways we might not fully understand.

Let’s start with deployment. I use this term because of the definition, “the arrangement or distribution (of resources such as people or equipment), in preparation for battle or work”. While my view of the world has shifted in recent years, I grew up captivated by everything military, and the word deployment made sense in my brain when it comes to making resources available. After more thought, I also like it because once you deploy an API, you are responsible for it until it is no longer deployed. Even though I know this is’t the case, I like to think that a team who is responsible for deploying an API is responsible for it until it isn’t deployed anymore, much like a military unit.

Similar to deployment, I like the term provide, because it makes me feel like there is a continued ownership or stewardship for the resource. If you provide an API, you have to support it, own it, and be responsible for what happens down the road. You aren’t just checking some box, and moving on, which I think represents much of the illness we see with APIs across the tech sector. If we are providing a resource, it feels like it is a sustained effort, which means we’ll stay engage with the process, and the consumers who we are providing this resources to. Which just feels healthier to me. If you are providing something, it is likely that you are the face of it, and have to be engaged, and have skin in the game, which is why you hear me describe people who have APIs as API providers.

Publishing an API feels like we are done once we publish it to the gateway or production server. I’m not sure it does the reality of API management justice. I’d say that producing an API has the same feel to it. Publishing and producing an API feels like we are off the hook once we have accomplished the task, and checked off this request. The ongoing evolution, support, and engagement around an API is just too important to diminish with the words we use. I see too many companies, institutions, and government agencies check the API box and move on, leaving a soulless API for consumers, with nobody home to answer questions, and provide the critical feedback loop. I guess that these terms could work within larger operations where there are separate teams in charge of publishing and producing than there are for managing and supporting, but for most API providers, I am thinking that we should use words that reflect the sustained nature of our obligation around the APIs we deploy.

I feel like the words we use are being define solely by vendors who want use to publish APIs to their platforms, encouraging us to produce the things that matter to them. This is fine, but I also think we should be thinking about the bigger picture of how we play the API game, and consider how we can incentivize teams to own more of the process, and take pride in not just producing APIs, but playing a sustained role in their deployment, and being willing to engage with consumers. I think that the words we use matter a lot. I think that it is too easy for us to be detached from the technical resources we are producing, and easily put up walls between us and those who are putting our APIs to work. I’d be curious to learn how your teams describe the process. Are they deploying, providing, publishing, producing, or some other way of bringing APIs to life? Or do you think it doesn’t matter in the end, as long as the API is made available for consumers to integrate into their desktop, web, mobile, device, and network applications.