API discovery has been one of the slower-moving aspects of doing APIs over the last decade due to the fact it is something that means many different things to many different people, depending on what their relationship to an API is. Defining what the meaning for API discovery goals are, acknowledging there are many different perspectives on what is API discovery, and knowing what it involves to move the conversation around it forward has proved challenging for the enterprise — pushing API platforms to step back and work to establish some goals around why they need to invest in API discovery and who will be better served by improving upon API discovery mechanisms.

When Streamdata.io works with clients on their API discovery efforts, we always sit them down to discuss exactly what their goals were when it comes to discovering new and existing APIs across the landscape. Here are the areas we focus on when talking about the reasons behind API discovery across the enterprise.

• New APIs: Being able to find new APIs as they emerge across the landscape. Keeping in tune with what is happening across the enterprise, within an industry, or just in general when it comes to introducing you to new concepts and ideas.
• Application development: Being able to discover and identify the right APIs to be using when building a specific application and ensuring that the best of breed resources are available for supporting the common, as well as the unique features needed to deliver any application.
• Team planning: For use as part of wider team planning and being able to articulate what is in production, what is being developed, and what is currently being defined and designed as part of a single group, team, or other aspect of an enterprise organization.
• External: Being able to find APIs quickly, as well as provide self-service discovery of services by clients, partners, and other external actors. Eliminating bottlenecks, delays, and other bureaucracy when it comes to moving relationships forward with external actors, and ensuring the enterprise can be more agile and flexibility in getting business done.
• Developing an API: A team is looking to develop an API and they want to understand if one already exists, or maybe better understand existing patterns in use by internal, partner, or even public API providers, helping teams conduct due diligence when developing any new API resource.
• Execution: Being able to find an API so that you can make a call to it in some code or through a client application like Postman. Bypassing the need to have a user interface always present for every digital resource and enterprise capability, helping business and technical users quickly execute common actions on a daily basis.
• Governance: Being able to quantify what APIs exist across any group, organization, domain, and the enterprise at any moment, and being able to articulate what resources they provide access to, what their capabilities are, and the quality and mature of each service that exists.

Depending on whether you are part of executive leadership, business users, developers, IT, partners, or even government regulators, the reasons behind doing APIs will vary, and reasons you want your APIs found will dramatically differ. With there being so many different reasons for embarking on an API discovery, there hasn't been much consensus and investment in the area of API discovery — which has left the enterprise landscape quite a miss after decades of web service and API development. This is pushing enterprise API leadership to have to begin asking more questions about why they want to be able to find APIs and begin setting in motion some practical approaches to solving the API discovery mess every enterprise group faces.