APIs.json As A Distributed Transport Layer For The API Economy

I'm working with multiple partners to define what I’d consider to be the firsts stops along the API lifecycle, when you use APIs.json as the scaffolding for your API operations. APIs.json is a machine readable format for indexing APIs, that exist under a specific website domain, or are part of a aggregate collection designed for a specific project or objective.

To help me, and the folks I’m working with to better see the API lifecycle that APIs.json is enabling, I wanted to take a stroll through each of the stops along the API lifecycle, and think through the potential for additional formats, services, and tooling throughout the entire journey. I want to explore the possibilities for individual API providers, API consumers, as well as API service providers, and the aggregate level, where companies and individuals are delivering valuable tools and services to the overall space.

First, lets start with what I envision APIs.json enabling at the direct one to one, API provider and consumer levels:

  • API Metadata - Quick access to the most important info about any API, its title, description, image, endpoint, url and tags.
  • API Surface Area - (The Truth) - Using Swagger and API Blueprint, any developer can quickly quantify the surface area of an API or microservice.
  • Execute API - Include Postman Collections, allowing each API to be execute ready, allowing consumers to load in Postman and deliver the value behind any API.
  • On-Board API - One click reference to where an API consumer can onboard with an API.
  • Existing Server-Side Code - Locating of existing server-side code in multiple languages.
  • Auto Generate Server-Side Code - Locating of services for generating of server-side code in multiple languages.
  • Supporting Container Images - Where Docker, and other container images reside, providing instant deployment opportunities.
  • Existing Client Side Code - Locating of existing client-side code in multiple languages.
  • Auto-generate Client Side Code - Locating of services for generating of client-side code in multiple language.
  • API Pricing - Understand pricing, access tiers, and partnership opportunities around API operations.
  • Terms of Services - Access, and make sense of terms of services that apply to API usage.
  • Licensing - Understand the licensing of an API, data, content, and code related with an API.
  • General Questions - Be able to ask, and get answers to common questions about any API.
  • API Conversations - Understand where to engage in conversations, and experience streams from common sources like Github and forums.
  • Augment APIs - Add endpoints, verbs, and parameters to existing endpoints, augmenting what any single API provider can deliver.
  • API Presets - Establish preset value for API entries, allowing the single, or bulk publishing of data, content and other values to APIs.
  • API Mapping and Domain Specific Language (DSL) - Bridging API definitions, and APIs, providing much needed aggregation and reciprocity for APIs.
  • API Sandboxes - Establish API sandboxes, based upon existing API designs, allowing developers to develop against alternative API than a production environment.
  • API Simulations - Beyond just a sandbox, actually establish alternative APIs that provide specific simulations of production scenarios that an API would serve.
  • API Cookbooks - Assemble API cookbooks that help onboard API consumers using wizards, blueprints, and other established orchestration patterns.
  • API Testing - Initiate API testing tools and services, covering surface area of each API.
  • API Monitoring - Initiate API monitoring tools and services, covering surface area of each API.
  • Audit Security - Audit surface area of any API that is indexed using APIs.json.
  • API Adjacent Monitoring - Initiate monitoring of other API adjacent resources like documentation, terms of services, and other essential building blocks of operations.
  • Visualize API Surface Area - Simple, embeddable visualizations that help us see the surface area an API provides.
  • Visualize API Resources - Simple, embeddable visualizations that help us interact with the resources APIs deliver.
  • Analyze API Surface Area - Simple, plug and plug tooling and services for analyzing the surface area of any API.
  • Analyze API Resources - Simple, plug and play tooling and services for analyzing the resources APIs deliver.
  • Load API Response In Spreadsheet - Resource for loading, and importing API resources into an Excel or Google Spreadsheet.
  • Craft experiences - Weave together experiences made up of multiple API resources, and the resources that are available to support them.

This list represents my master vision for stops along the API lifecycle, that could be served via APIs.json, providing value directly to API providers, and their consumers. Each of these areas would benefit both sides of the API coin, but as you can see will add value to the APIs.json engine, in a way that goes well beyond just API discovery--which APIs.json is known for.

It is hard for me to articulate, and map out the opportunities that will be available when APIs.json is fully realized. Our goal is to push the number of APIs.json files available to a critical point, where this full lifecycle vision is a reality. Once this occurs, I see another plane of existence emerging, one that can be applied across hundreds, or thousands or public or private APIs and micro services.

Once a critical mass with the number of APIs.json files is achieved, the wider opportunities for expansion, growth, and monetization will span three main areas in my mind:

  • API Definitions - Additional API definitions like Swagger, API Blueprint, and API Commons, providing machine readable access to vital components of API operations, that can be baked into the overall API lifecycle.
    • API Pricing - A machine readable format for breaking down pricing, access tiers, and partnership opportunities around APis indexed with APIs.json.
    • API Questions - A machine readable format for aggregating questions around API operations, including terms of service, privacy policy, and other elements that impact API integration.
    • API Conversations - A machine readable for for aggregating conversations that occur around API operations, that occur on multiple channels like Github, Stack Overflow, Twitter and more.
  • API Services - The opportunity for new API services to be developed on top of the APIs.json lifecycle.
    • Testing - Introduction of testing related services to known, and custom APIs definitions.
    • Monitoring - One time and schedule monitoring services, triggered via APIs.json indexing.
    • Security - Scanning of entire API surface area defined by an APIs.json definition.
    • Broker - Use of APIs.json in API broker related activity, crafting custom API backends and stacks.
    • Analyst - Delivery of vital industry and area data and content, using APis.json format, connecting analysis directly to sources.
  • API Tooling - The opportunity for new API tooling to be developed on top of the APIs.json lifecycle.
    • Search - Continued growth in the number of API search engines like APIs.io, providing options, and competition.
    • Collections - Establishment of common tooling for doing API roundups, collections, stacks, or any other grouping that is defined.
    • Notebook - Deployment of tools for saving, organizing, and remixing using APIs.json formats, either publicly or privately.
    • Spots / Hubs - Deployment of API spots and hubs that allow aggregation of API definitions, supporting building blocks, and API consumers in a wide variety of API areas.
    • Dashboards - Deployment of dynamic, APIs.json driven dashboards that generate visualizations, listings, and other detail via machine readable API definition formats.
    • Infographics / Reports - Deployment of dynamic, APIs.json driven infographics, reports that generate visualizations, listings, and other detail via machine readable API definition formats, in a portable format.

That is just a sampling of the definition, services, and tooling opportunities that are already, and will eventually emerge around an APIs.json driven lifecycle. The objective of this post was to flush out my ideas around the one to one, and the wider API economy opportunities using in APIs.json driven API lifecycle, for my own purposes, but also to communicate my thoughts to a handful of partners who are executing definitions, services, and tooling already.

If you are curious about what this all means, and get more clarification about how your company, its services and tooling fit into this, feel free to reach out, and I’ll do what I can to help you understand where you fit. Some of the stops along this API driven supply chain, I’m depending on existing efforts like Swagger and API Blueprint to execute, some of the areas I’m pushing forward myself like API Commons, API Pricing, API Questions, and API Conversations, while other areas I’m depending on 3rd party individuals and companies to step up and own. If you think you might be interested in delivering an API definition, service, or tooling somewhere in the areas I’ve defined, feel free to reach out.

This post is a product of several conversations I’m having with folks, and the regular conversations that Steve Willmott (@njyx) of 3Scale, and I are having around the APIs.json format. Additionally we are currently working on the roadmap for APIs.io with Nicolas Grenie (@picsoung), which is the first of many tools that are being built on the APIs.json format. You can influence the roadmap for APIs.json via the Github repo, and the individual communities of each of the sub APIs.json API definitions formats like Swagger, API Blueprint, API Commons, on their own working sites and repos.

If you made it this far, thanks for listening! ;-)