Trying To Define API Awareness

I have a regular call with a really smart API person who is trying to move forward a really cool project for the API space. It is some thought provoking voodoo and I need to be able to write about it--this is how I flush out my thoughts and move forward. He is not quite ready to talk about his project publicly, so I will just talk about and explore in terms of my API Evangelist research and how it applies to the area(s) of the API space he is looking to make an impact.

This topic spans several areas of my API research, but if I had to give it a single label I would call it API awareness. When you hear me talk about my monitoring the API space, API awareness is the result. I wanted to try and communicate this from my vantage point but also share with other analysts, practitioners, and even the average individual online today. This is my attempt to distil my approach to monitoring the API space and establishing a sustained awareness of APIs at any level.

Individual ("Normals")
It may sound crazy to you, but everyone should be API aware. No, they should be paying attention to APIs like I do, or even at the level of the average individual working in the tech sector, but they should have a baseline awareness, and here is my attempt at quantifying that:

  • APIs Exist - Everyone should be aware that APIs exist, and hopefully have one or two examples of what they can do in their business or personal lives -- even if it's' just pulling tweets, photos, or getting news updates via an RSS feed.
  • API Integration - Everyone should be aware that they can move data and content between the online services they use and depend on. If you know APIs exist and are aware of services like Zapier or Datafire, you will be more successful in what you do online.
  • Data Portability - All online services should allow for the downloading of their data, allowing for the portability of all users data and content.
  • API Discovery - With a low-level awareness of APIs and what is possible, the average individual should regularly be introduced to new APIs, and be given simple tooling and services for helping them in their discovery.
    • Applications - Everyone should get exposed to what other people are doing with APIs, and be informed about new and interesting ways to get things done for fun or business.
    • Individuals - Individuals within a company, institution, or online that can help with APIs.
    • Organizations - Organizations that can help individuals with API needs.
    • Events - Meetups, conferences and other events to learn about APIs.

The more we expose the average person to APIs, the more they will be able to absorb and understand. I've turned hundreds of average, non-technical folks on to the concept of APIs, and have seen them become evangelists and even API practitioners. Some move into API focused roles, but many are just are more successful in what they are already doing, from social media work to sending out their weekly newsletter.

I've always put API awareness for individuals into the same bucket as financial awareness. You shouldn't have an awareness of the inner workings of banking and credit industry, but you should have an awareness that you have accounts, who has access to them, and that you can move money around, and have different accounts for different purposes, with different providers--the same applies to the world of APIs.

API Practioners ("Not Normals")
When I first started writing this post, I had this section broken up into three groups: 1) Provider, 2) Service Provider, and 3) Analysts. Much of it ended up being redundant, so I'm going to share the complete list of what contributes to my API awareness, and depending on where you exist in the API spectrum (gonna have to use this one more), what matters to you will vary.

This is a master dump of my research, and the approach I have used to track on in the world of APIs since 2010--an analyst 100K view. However, API providers, service providers, evangelists, and analysts should possess a similar level of awareness--maybe not at the scope I pay attention to but employing some of the same tactics, applied to a smaller group of APIs either internally or externally. Here is what I'd consider a comprehensive definition of my API awareness stack.

  • Exist - Everyone should be aware that APIs exist, and hopefully have one or two examples of what they can do in their business or personal lives--even if you are in a business unit, you should know about APIs.
  • Discovery - With a low-level awareness of APIs and what is possible, the average individual should regularly be introduced to new APIs, and be given simple tooling and services for helping them along in their discovery.
    • Applications - Find new applications built on top of APIs.
    • People - People who are doing interesting things with APIs.
    • Organization - Any company, group, or organization working with APIs.
    • Services - API-centric services that might help solve a problem.
    • Tools - Open source tools that put APIs to work solving a problem.
  • Versions - What versions are currently in use, what new versions are available, but not used, and what future versions are planned and on the horizon.
  • Paths - What paths are available for all available APIs, and what are changes or additions to this stack of resources.
  • Schema - What schema are available as part of the request and response structure for APIs, and available as part of the underlying data model(s) being used. What are the changes?
  • SDKs - What SDKs are available for the APIs I'm monitoring. What is new. What are the changes made regarding programming and platform develop kits?
    • Repositories - What signals are available about an SDK regarding it's Github repository (ie. commits, issues, etc.)
    • Contributors - Who are the contributors.
    • Stargazers - The number of stars on SDK.
    • Forks - The number of forks on an SDK.
  • Communication - What is the chatter going on around individual APIs, and across API communities. We need access to the latest messages from across a variety of channels.
    • Blog - The latest from each API blog.
    • Press - Any press released about APIs.
    • Twitter - The latest from Twitter regarding API providers.
      • Tweets - The tweets from API providers.
      • Mentions - The mentions of API providers.
      • Followers - Who is following their account.
    • Facebook - The latest Facebook posts from providers.
    • LinkedIn - The latest LinkedIn posts from providers.
    • Reddit - Any related Reddit post to API operations.
    • Stack Overflow - Any related Stack Overflow post to API operations.
    • Hacker News - Any related Hacker News post to API operations.
  • Support - What support channels are available for individual or groups of APIs, either from the provider or maybe a 3rd party individual or organization.
    • Forum / Group - What is the latest from groups dedicated to APIs.
    • Issues - What are the issues in aggregate across all relevant repositories.
  • Issues - What are the current issues with an API, either known by the provider or possibly also reported from within the community.
  • Change Log - What changes have occurred to an API, that might impact service or operations.
  • Road Map - What planned changes are in the road map for a platform, providing a view of what is coming down the road.
  • Monitoring - What are the general monitoring statistics for an API, outlining its overall availability.
  • Testing - What are the more detailed statistics from testing APIs, providing a more nuanced view of API availability.
  • Performance - What are the performance statistics providing a look at how performant an API is, and overall quality of service.
  • Authentication - What are all of the authentication approaches available and in-use. What updates are there regarding keys, scopes, and other maintenance elements of authentication.
  • Security - What are the security alerts, notifications, and other details that might impact the security of services, or the approach taken by a platform to making sure a platform is secure.
  • Terms of Service - What are the changes to the terms of service, or other events related to the legal operations of the platform.
  • Privacy - What are the privacy-related changes that would affect the privacy of end-users, developers, or anyone else impacted by operations.
  • Licensing - What licenses are in place for the API, its definitions, and any code and tooling put to use, and what are the changes to licensing.
  • Patents - Are there any patents in play that impact API operations, or possibly an entire industry or area of API operations.
  • Logging - What other logging data is available from API consumption, or other custom solutions providing other details of API operations.
  • Plans - What are the plans and pricing in existence, and what are the tiers of access--along with any changes to the plans and pricing in the near future.
  • Partners - Who are the existing platform partners, and who are the recent additions. Maybe some finer grain controls over types of partners and integrations.
  • Investments - What investments have been made in the past, and what are the latest investments and filings regarding the business and investment of APIs.
    • Crunchbase - The latest, and historical from Crunchbase.
    • Angelist - The latest, and historical from Angellist.
  • Acquisitions - What acquisitions have been made or being planned--showing historical data, as well as latest notifications.
    • Crunchbase - The latest, and historical from Crunchbase.
    • Angelist - The latest, and historical from Angellist.
  • Events - What meetups, conferences and other events are coming up that relevant APIs or topics will be present.
  • Analysis - What tools and services are available for further monitoring, understanding, and deriving intelligence from individual APIs, as well as across collections of APIs.
  • Embeddables - What embeddable tooling are available for either working with individual APIs, or across collections of APIs, providing solutions that can be embedded within any website, or application.
  • Visualizations - What visualizations are available for making sense of any single API or collections of APIs, providing easy to understand, or perhaps more complex visualizations that bring meaning to the dashboard.
  • Integration - What integration platform as a service (iPaaS), continuous integration, and other orchestration solutions are available for helping to make sense of API operations within this world.
  • Deprecation - What deprecation notices are on the horizon for APIs, applications, SDKs, and other elements of API operations.

API awareness spans many stops along the API lifecycle, and across a variety of the most common, and critical building blocks of what drives API ecosystems. Awareness doesn't come easy. It takes time, and have access to the right information, and signals, potentially across many different entities and domains--aggregating, filtering, and ranking is essential developing and strengthening your awareness. In the end, even with the same signals and information available, there will be many definitions of what is the necessary awareness.

I am glad I didn't break this into different buckets for different people. I think that is a dangerous thing for us to do. I think people should be curious and have agency the decisions regarding which signals should feed their awareness. How many APIs. Which APIs. Which companies, news, events, and other areas. Investment, patents, and other legal aspects. I don't think that all individual should be bombarded with the more complex inner workings of the API industry I pay attention to, but they should be able to make the decision to move beyond a basic level of understanding, and become an evangelist, or analyst--quantifying and developing the awareness they desire or need to achieve.

I'll stop there. This is a good first draft of what I consider API awareness. At the individual API level, across a collection or industry of APIs, and even at the analyst levels, potentially paying attention to many different APIs across a variety of different industries. Before I put this definition down, I am going to take it and apply it in two other ways: 1) Observability, "measure for how well internal states of a system can be inferred by knowledge of its external outputs", and 2) Rating, "establish a rating system that articulates where an API or provider exists on awareness and observability spectrum". We'll see where it goes. Thinking about this voodoo is helping me better organize some of the existing parts of my research, and hopefully help my friend out in his work as well.