According to  industry  analyst firm 451 Group  , the average number of  APIs  currently  owned by enterprises exceeds  15,000  .  Obviously, this number is much higher than  the average number of  APIs that a platform operations team can track with a spreadsheet . Even if the API responds Tracking is distributed to various business units, it is still a daunting task given the incredible growth rate of the number of APIs .         

In 2021, F5 engineer and technologist Rajesh Narayanan coined a new term for the problem:  API  sprawl  .  The term "API sprawl" is exactly what it sounds like—that is, the accelerated growth of the number of APIs in enterprises around the world, Which has also brought huge challenges to API management and protection.  How serious is the problem?  Narayan estimates that by 2030, there will be more than 1 billion APIs deployed and running globally.

Changes in the way modern applications are developed has accelerated API sprawl.  The rise of microservices, the increasing number of APIs used for system internal communication, and the rapid increase of multi-cloud and hybrid cloud architectures have made us need to use more APIs to communicate between applications.  For example, Kubernetes, the de facto standard for container orchestration, uses an API for all internal communication.  New types of infrastructure (such as serverless architectures) also mean that APIs can run in almost any also environment.  There are wider variety of API technologies to manage—REST, GraphQL, and gRPC are all widely used, and more API query protocols will appear soon.

To make matters worse, cybercriminals absolutely love API sprawl.  They are increasingly targeting APIs with their precise attacks because APIs are often not carefully managed and have relatively open access by default.

To eliminate this problem, the challenges of API management, discovery, and protection must be addressed with programmatic, scalable solutions.  But before you can  effectively  combat API sprawl  ,  you need to understand the extent of the problem in your organization.  Here are six clear signs that you have an API sprawl problem.

1. No recently updated API list

A classic symptom of API sprawl is not knowing which APIs are running in all environments, and this is often the result of a loose API management policy where teams don't register APIs that are only used internally (so-called "Shadow API") .

Your first task is to take an accurate inventory of your existing APIs.  However, since the addition and deprecation of APIs are usually extremely frequent, continuous statistics are required to "accurately take stock".  A logical solution is to programmatically take inventory and do continuously API discovery, similar to network scanning and asset discovery.

In theory, a structured API approval process would also help.  But in reality, for tasks such as API creation and version management, enterprises that are constantly "shifting left" will want to reduce the onerous approval process.  It's often a good approach for these businesses to build out API inventory as part of CI/CD, especially when APIs are used in microservices and other more modern application architectures.

2. Not knowing where each API is running

In a modern infrastructure environment, it's not enough just to know that an API exists -- you also need to know where each API is located.  Endpoints may mirror each other between containers in different infrastructure forms - across multiple clouds, in a hybrid cloud, or in multiple services like serverless.

Security teams need to know the location of APIs to properly configure policies and safeguards and run API security tests. This also affects your choice of API Gateway and other means of managing API traffic if you need to run your API in multiple environments . Ideally, you would like to have a global API gateway solution so that you can achieve consistent API traffic management and protection in different environments.      

3. Can't easily identify the owner or person in charge of the API  If you don't know who is responsible for the API, when there is a problem with the API, you don't know who to contact.  Oftentimes, APIs that are integral to smooth operations become orphaned when the person or team building the API moves or leaves.  Sometimes the transfer of API ownership is very explicit - but more often the process is skipped or done informally.

As part of the inventory process, assigning ownership to each API is critical because it establishes accountability and helps responsible parties properly manage and secure the APIs they are responsible for.

4. Multiple APIs are performing similar or repetitive tasks

Task overlap often happens when multiple teams have similar but not identical needs, and someone says, "We'll build our own API to meet our needs, so we can control our own destiny! "However, having multiple similar APIs adds unnecessary technical debt .  Therefore, it is important to measure how many applications or services consume APIs as one of the key performance indicators (KPIs).  Tracking these metrics helps maximize the reusability of each API.  Another way to integrate APIs is to switch to a more flexible form like GraphQL.

5. Documentation lagging by more than 2 versions

Documentation is critical to experience transfer, new employee orientation, and organizational resilience.  Unfortunately, writing and maintaining documentation is usually the thing engineers hate the most.  Outdated API documentation is often a sign that the API is sprawling — because it means that the team is creating and updating the API so quickly that they don't have time to update the documentation — or they can plausibly explain their failure to update the documentation.  At worst, outdated documentation indicates that the APIs mentioned are orphans that are not maintained.

Fortunately, APIs tend to have a clearly defined structure, making them easy to understand.  A good API management solution usually includes a tool to help developers automatically generate documentation according to the API specification. One of  the most common examples is  the OpenAPI  specification  .  uses a standard format to describe an API so that humans and computers can discover and understand what the API does without having to access source code or other documentation.

6. The project was delayed due to API security protection

Good news?  The security team checks all APIs before release.  What about the bad news?  Because the API owner did not follow API security best practices during development, or did not conduct adequate testing, the inspection failed and the code was sent back for rework .  And better news?  It's not that hard to come up with a consistent set of general rules and best practices to help developers implement most of their requirements—basic approaches include enforcing rate limits, encrypting external traffic, and requiring rekeying for key regenerator. etc.  Most businesses can also implement additional protection against the  10 most common API attacks  listed OWASP 

More advanced organizations with mature SecDevOps capabilities can perform threat modeling for each API, and may also be able to assign different security levels to different APIs based on the type of data or services that can be accessed.

Conclusion: Avoiding sprawl is a never-ending struggle  These six signs are just some of the early warning signs of the phenomenon of API sprawl.  Let's be clear - API sprawl is a natural outgrowth of developer autonomy and DIY thinking in microservices.  Building new APIs is becoming easier and more feasible with modern development tools and code automation capabilities like GitHub Copilot.

The work of dealing with API sprawl is endless.  Deploying an API management solution and an API gateway can be a powerful boost - if developers don't use an APIM (API Management) solution for their APIs, the gateway may shut down their APIs - this is demanding, but it is necessary for security protection.

Fortunately, the measures taken to mostly align with common API management approaches. Over time, these measures can eliminate technical debt and avoid fixing APIs with supplementary security measures later in the development process or after release, ultimately allowing to development increment velocity.    

If APIs are the lifeblood of a business, API sprawl is one of the biggest threats to business health.  Careful and proactive API sprawl controls pay huge dividends and ultimately improve developer satisfaction.