If you’re building APIs, your biggest expense is almost certainly your developers’ time. But what are your current API tools doing to maximize that limited resource? If you follow the widespread advice surrounding API lifecycle management, the answer is likely “not much.”

You can’t manage your way into an API — you have to develop it. That means building tools and practices that support how your developers work: one endpoint at a time.

API Management Does Too Much and Not Enough

Most API tools on the market are based on API lifecycle management, an adaptation of product lifecycle management (PLM). PLM has been around since the 1930s, and its application to APIs came alongside the growth of Agile methodologies and the growing role of project managers in engineering organizations.

Too Many Steps, Too Many Meetings, Too Many Tools

What is API lifecycle management? It’s a set of practices that begins with API design but tends to diverge across companies. It may be five phases, six phases, or more. Even without broad agreement on the stages involved, most project management approaches require engineers to attend meetings and review documentation at every step.

API management tools follow suit — there might be a different tool for every stage or one clunky tool that attempts to cover everything. Managing processes and tools starts to be more work than actually writing API code.

No one wants to write inconsistent, redundant code, but when teams and tools take a 5,000-foot, product-level approach, it happens more than it should. A kitchen where every cook has a hand in every pot is not a recipe for success.

Not Enough Practical Support

At the same time, those bloated tools and practices don’t offer features that individual engineers actually need, and certainly not with any efficiency. No one will create a better hammer by looking at a finished house. But any carpenter will tell you that quality tools make all the difference to the finished product.

Building endpoints is like the basic carpentry work of an API. If you take a product-level view of the API, it’s easy to lose sight of the day-to-day labor that goes into creating it.

To make a hammer that carpenters love, you start by watching them work. You focus on reducing fatigue and improving the ergonomics of every hammer stroke. You look for durable, comfortable materials and make micro-adjustments to angles and curves, knowing it takes thousands of hammer strokes to build a house.

To build better APIs, you must look at your developers and how they work. For API developers, the unit of work is the endpoint. You need tools that reduce fatigue and improve efficiency for the lifecycle of an endpoint — a process your developers will repeat hundreds or thousands of times as they build an API.

Modularity Is an API Hallmark

When a tool is well-suited to the user and the basic unit of work, it’s efficient for a wide range of projects. A good hammer is useful for building a deck, installing cabinetry, or nailing up a “For Sale” sign. It serves all these purposes without being made to fit any particular process or product design.

All APIs are built of individual endpoints, whether small, private microservices or enterprise products. That architecture makes APIs extremely modular and adaptable. Depending on their needs, API consumers can use a handful of endpoints or hundreds. Endpoints can be reused for different purposes and must be easily discoverable to make that work.

The same applies to API tools — they can and should be modular and reusable. When you reduce the overhead of your tools, you can focus on the value and purpose of the API rather than a clunky all-consuming process. That means leaving API lifecycle management behind and focusing instead on the lifecycle of an endpoint.

How Are Endpoints Built?

The goal is to find — or create — tools that let your developers focus on the lifecycle of an endpoint. But what is the lifecycle of an endpoint? It looks something like this:

1. Gather requirements.
   1. Describe the required functionality, which is included in the API Spec.
   2. Look at data to understand the shape of the object the endpoint will touch.
2. Write code.
   1. Boilerplate code for basic endpoint structure.
   2. Custom code for endpoint functionality.
   3. Error handling.
3. Debug and test code.
   1. Write and run some simple tests.
   2. Check in code and resolve conflicts with existing codebase.
4. Deploy.
   1. Gather data on usage.
   2. Update code as needed.

It’s not a hugely complicated process, but it gets repeated hundreds, if not thousands, of times while building an API. Any efficiency gains you make in this process will pay off in spades.

Endpoint Lifecycle Management Isn’t a Compromise

Giving up the laser focus on API lifecycle management doesn’t mean giving up on governance or code quality. It’s not a choice to silo developers away from product and consumer concerns. And it’s not any kind of denigration of the work of product and design teams. If anything, it’s the opposite.

Shifting your emphasis to endpoint lifecycles empowers everyone in the organization. Developers can focus more deeply on code quality, repeatability, and discoverability. Designers expend energy on the products and services that most need their expertise. Cost savings and quality improvements pay off, resulting in better results and more resources to allocate to innovation.

API lifecycle management had its moment. Collectively, the API industry has matured and evolved in significant ways since that approach started, in part because of what teams learned from the process. However, the approach has outlived its usefulness. API teams must stop managing down, requiring developers to fit their work into a clunky, tired process. Refocus on the lifecycle of an endpoint and let developers get back to the work they’re best at with tools that serve their needs first.