When I get asked by folks about where they should start with APIs, I always start with the low hanging fruit on their websites--if it is publicly available as HTML on your website, it should be available as JSON or YAML via an API. After that, I recommend people start with the software and systems a company is already using and might have APIs or data outputs. Your existing technology most likely has APIs or the ability to publish machine-readable data, and you are just not taking advantage of their capabilities as part of any larger API strategy.
I recommend launching a new developer portal using Github and get to work inventorying all of the software, systems, website, and services you use. It doesn't have to be public, you can make your repository private if you have any concerns. Profile each of the technological solutions you are using on a regular basis, and see if it has an API or not. If it doesn't, why the hell are you using it? Ok, well maybe that is another discussion. If it has an API, add it to your API list, and set it aside for profiling in more detail, developing a better understanding what is possible.
After reviewing all your existing software, and now possessing a list of companies who do have APIs, let's get to work profiling them, and bring together into a coherent 3rd party API strategy for your operations:
- Developer Portal - Where do we find documentation and other resources for each API?
- Pay for Service - Are we paying for a service? What are the pricing and plans for each API?
- Documentation - Where is the API documentation for each API we are including in our catalog?
- OpenAPI Definition - Create or obtain an OpenAPI definition for each API, allowing it to be used in operations.
- Support Information - Where do we get support for an API? Are there multiple options, or possibly paid solutions?
- Road Map & Change Log - Where do we find the roadmap, status, change log, and other aspects of API operations?
- Code & SDKs - Where do we find code and other open tools for an API? Which are forked, copied, or implemented for our operations?
- iPaaS Solutions - Can we identify and share common integration patterns, and put to use services like Zapier as part of our operations?
APIs are not just about providing APIs, it is also about consuming APIs. Google Apps, SalesForce, Office 365, and many of the software solutions you are already putting to work have APIs. There should be a single portal you can go to and understand what is possible when it comes to APIs You should be able to find code, tools, and communication around existing usage, integration, and other projects at your company. API portals are often confused as something you do for a single API, providing direct access to data, content, and algorithms, but there is no reason a portal can't also contain access to other 3rd party APIs that also benefit your operations.
The public or private API portal for your company, organization, institution, or government agency doesn't have to only possess your APIs. It makes perfect sense for you to aggregate the APIs from across the software solutions you use, cultivating a central place to find everything regarding 3rd party API integration at your company. In addition to low hanging fruit, it provides a great way to kick off an API effort at your company, focusing on the digital resources that are already being used, allowing you to learn more about an API way of life before you consider tackling more complicated API efforts.
