A Minimum Viable Existence For Four Of My New APIs

I have a whole bunch of APIs I want to deploy. There is a queue of APIs that I will never get to, but I can't help myself, and when I am tired of watching what everyone else is doing, and want to get busy actually building things, I crack open my queue of ideas. This weekend I launched four new APIs, that will be in the service of some very different objectives that I have.

  • Low Hanging Fruit - Identifying the potential CSV, XLS, XML, and table resources that exist in any domain, and publish them to Github as a list for deploying as APIs - aka the low hanging fruit.
  • TSA.Report - A simple form for submitting your thoughts as you are going through the airport line.
  • APIs.How - The URL shoretner for the API Evangelist and Kin Lane network--getting off Bitly.
  • Magnetic Jargon - A dictionary creation API, allowing the building of word lists to use for a magnetic fridge web and mobile app I am building.

Each of these APIs have a specific purpose. Low Hanging Fruit, and APIs.how are both very back-end system tools, where TSA.Report and Magnetic Jargon are meant to drive simple web and mobile applications. The purpose of these applications are not the point of this story, the minimum viable existence of these four new APis is what I want to talk about.

These four APIs are far from complete. I anticipate that TSA.Report and Magnetic.Jargon will evolve based upon the apps that are developed on them, but Low Hanging Fruit and APIs.How are core to how I do business, and will continue to evolve as far as I can afford to scale them (ie how many sites and links I can index). 

My goal this weekend, is to just get the APIs up and running. Their overall relevance and productivity in my world will be decided by their roadmap. I just needed to establish them as a real project, and get a mimum viable definition up and running. Here is what defines a minimum viable API in my world right now:

  • API - One or many endpoints that serve data, content, or other resources via one of my domains.
  • Swagger - A JSON definition of the surface area, and underlying data model for any API I provide.
  • API Blueprint - A markdown definition of the surface area, and underlying data model for any API I provide.
  • Postman - A Postman Collection allowing anyone to quickly deploy an API in a Postman Client.
  • API Science Monitor - At least one monitor of one of the endpoints, acknowledging it is up and running.
  • APIs.json - Providing an index of each project, giving me machine readable access to each API, as well as its operations.
  • Github Repo - A repository to house the server code (privately), but also publish a developer portal with API definitions available via a known location.

This the current minimum viable definition of an API in my world currently. I will be adding more endpoints to each of these APIs, as well as other building blocks to support their operations, but this represents the start for each of these projects for me. 

Honestly I do not know if each of these APIs will survive. They will each have their own road-maps, one that is driven based upon how much I evangelize, and ultimately attract interest from consumers. Each API will have its own monetization strategy, something I will work on sharing via the API definitions that I've published in their API portals. 

Two of these APIs are core to my operations as API Evangelist, while two of them are just really for fun, and are in support of simple micro apps I wish to deploy. Low Hanging Fruit will depend on how much funding I can get for each domain indexes, and APIs.How will thrive based upon the growth of my own writing and storytelling. The other two will be driven by advertising revenue, and I do not expect anyone to actually build anything else on the APIs, they only exist because I am API-first in everything I do.

Now that I have a minimum viable existence for all four of these APIs I can move into the next next steps for each project, while also addressing other items on my task list, but at least I know these projects are up and running, and discoverable when I get time to get back to them.