Definition of The API Lifecycle

From conception to deprecation, a Software-as-a-service (SaaS) is prone to constant evolution. Check the changelog for a high-volume platform like Dropbox. In such logs, you’ll find bug fixes and updates, with the latest likely made within the past couple weeks.

The APIs that open these SaaS platforms are changing just as rapidly. So much so that API Changelog was created to notify users of API documentation changes (22 updates in the last 30 days in the case of the Dropbox API at the time of this writing). This ongoing iterative process is not only Agile, it’s evolution is in symbiosis with many business factors that make up the organism that is the entire API lifecycle.

As the main function of web APIs is to be consumed by third party products, the API is a unique type of business offering. It’s peculiar condition as both a software and internal asset makes its lifecycle special – highly fueled by ongoing feedback and market validation. Compared with standard SaaS products that may have the power to change their UI or underlying construct, an API’s granular state can make it even more elusive.

The State of Modern Software Development

Agile…Scrum…contemporary software development pushes toward quick releases and fluid responses. Response to change needs to be rapidly executed, leveraging user feedback, data, and statistics. These traits are becoming standard practice throughout the software realm. But is producing and maintaining an API the same – or is it a different animal entirely?

The API As a Living, Breathing Organism

Exactly how an API lifecycle looks depends on how the API functions as well as the business strategy at it’s core. We at Nordic APIs have boiled down the common API lifecycle to 4 main phases. Mapped out, these elements work together as such:

What’s With All The Arrows?

Once the cycle begins, open and simultaneous exchange between each phase will help a practitioner stabilize the API against internal and external factors. Factors that arise within each stage may beckon a team to move forward or backward in the lifecycle, encouraging small revisions or large pivoting to reach end project goals.

#1: Analysis Stage — Determine API Business Strategy

So, you want to build an API. Before you build the programmatically accessible platform of the future, the first step should be defining the API business objectives. Firms should critically ask themselves whether or not an API is right for their particular situation.

Some industries, such as social networks, thrive off APIs as a natural extension of their digital ecosystem. On the other hand, traditionally non-digital companies, such as Marvel comics, have to be creative in handling how APIs extend their business model.

An API should either boost pre-existing operations or work toward overall company goals in some way. In our eBook Developing the API Mindset we defined 3 types of APIs:

• Private APIs streamline internal operations to decrease expenses.
• Partner APIs work specifically with partner organizations to expand a services’ reach to existing markets to generate revenue.
• Public APIs form new ecosystems by opening up a service for public access. If you intend to have a public release, obtain feedback while you perform analysis to gauge interest and determine access control.

Next Steps:

Whatever the chosen API strategy is, it’s mission statement, usage projections, model for growth, marketing strategy, and estimated financial return should be clearly laid out before production begins. If you’ve done the necessary preparation, it’s time to move to the Development Stage.

#2: Development Stage — Prepare and Construct

With business proof and goals laid out, the next step is defining technical requirements and opportunities that are in cooperation with the API strategy. Development plans need to consider the following:

• what operations the API will execute
• management and hosting
• the methods and protocols used
• size and scalability
• access and security control
• usability and experience
• the development team… among other factors

An intimate understanding of API processes will help form technical requirements. For example, knowing whether your API will open your firms’ data, or act as a content distribution channel can impact overall design.

In general, the API development stage should mimic the business objectives set forth within the Analysis phase. A methodical development phase considers design, construction and testing of API processes as well as security. Design your API with both human usability and machine standards in mind. It is a good idea at this point to also implement and evaluate API versioning strategies that will set the API in a good position for future updates.

Next Steps:

During the Development Stage, a team may choose to return to the Analysis Stage to perform additional market research and general preparation. This can arise from technical roadblocks, or the urge to revision an APIs’ primary objectives. If the API feels polished, tested, secure, and ready for general use, you are ready to move to the Operations Stage.

#3: Operations Stage — Foster a Userbase, Fix and Re-Fix

If you’re team’s lean as flank steak, you may be sprinting a Minimum Viable Product straight to the masses. With loose nuts and bolts, it’s natural that the Operations Stage will involve a lot of tweaking and bug-fixing.

Marketing a Public API Program

To spread awareness, API providers can host hackathons, improve SEO for home page and documentation, have a dedicated @Dev channel, and use popular discoverability methods and channels. If the resources are available, companies should also employ a dedicated API Evangelist to promote the API at physical events and throughout the blogosphere.

But in the end, marketing an API depends on an inside-out approach. Having an easy-to-consume development portal, an embedded help desk, along with other DX driven suggestions we’ve laid out in the past will help boost conversion rates.

Iteration Upon Iteration

This part of the lifecycle will likely take the most energy and time. Monitor usage statistics, and engage with users. Use any helpful data to aid in constant revisioning. Especially if an API program is in a closed beta, inbound tactics to collect feedback will help tremendously to aid in this iterative development process. Make sure that all API changes are well documented on your release notes.

Next Steps:

This exciting stage will bestow on an API practitioner real market requirements, and could potentially expose a business to entirely new opportunities. Statistics and data collected here will impact tech requirements that could result in revisiting the Development Stage to make incremental changes or new API versions, or consulting the Analysis Stage to make larger pivots. If forecasts look grim, a team may consider moving to the Retirement Stage at this point.

#4: Retirement Stage — Major Versioning & Deprecation

Old age comes, and retirement is a part of life. It’s no different in the API world. The retirement of the LinkedIn, Netflix, Google Earth, and ESPN APIs are examples of some recent large public API deprecations.

Factors that influenced these major deprecations were things like:

• limited use
• outdated plugins or lack of support
• a lack of 3rd party developer innovation
• opposing financial incentives
• privatization of data to limit the exposure of primary business assets
• security concerns… among others

Netflix, for example, reigned in their public API to focus more on partner integrations. In the case of ESPN, their reasoning to retire their sports data platform was “to better align engineering resources with the growing demand to develop core ESPN products on our API platform.” In both cases, what we learn is that by exposing assets, a business may risk losing an advantage if doing so decreases traffic from native distribution channels.

Next Steps:

A doctor must always check the patient’s pulse. Versioning, deprecation, or lassoing in an API into a more internal state are options to consider if your Key Performance Indicators (KPIs) are showing a flatline. At this point, the Analysis Stage can be reattempted, and the lifecycle repeated if viable. A Public API may still prove profitable as a Partner offering, for example. Retiring an API or API version is the best option when the API no longer is the best solution to reach the goals of the business. Whatever the solution is, we recommend a transparent public announcement that offers a reasonable timeline.

Overview of the API Lifecycle

In this brief article we’ve given a 30,000 foot view of the somewhat untraditional API Lifecycle. For more, continue reading The API Lifecycle series:

1. Introduction: Envisioning the API Lifecycle
2. Analysis Stage: Preparing your API Strategy
3. Development Stage: Deploying Your API
4. Operations Stage: Marketing Your API
5. Retirement Stage: A History of Major Public API Retirements — The Ultimate Guide