Fork me on GitHub

I feel we have done a good job explaining what is an API, why people need APIs, and providing services to manage APIs, but we are falling short on delivering information, tools and services for deploying APIs.

First I want to acknowledge that many companies have established IT resources, in the form of technology talent, and internal systems they can put to use when deploying APIs. This post isn’t for you. This is about individual problem owners looking to deploy APIs, who most likely have little or no access to traditional IT resources for a variety of reasons.

You want to deploy an API, because you havplease some data, content or other resources you need to make accessible to partners or the public, allowing for integration into other systems or be used in the development of web or mobile applications or possibly even data analysis and visualizations.

Machine Readable

As much as I love APIs, I suggest everyone consider your overall objective behind launching an API. You may not need an API, you may just need to make your information machine readable and available on the open Internet. Technically, this isn’t an API, but publishing your data or content in a machine readable format like XML or JSON can accomplish many of the same goals of an API, without the overhead of an API.

Many tools you use every day like Microsoft Office, Google Apps, Salesforce provide tools for publishing data and content in machine readable formats like CSV, XML or JSON, much like publishing or printing as a PDF. Not everyone needs an API, but everyone needs to understand the how-to, and the benefits of making machine readable a default in all business, organization, government and even individual processes.

PDF made data and content portable, for humans. But a PDF does very little good for other machines, websites and mobile apps. CSV, XML and JSON make data and content portable, while also making them machine readable. Please consider this simple evolution, while planning your API.

Machine readable will go far to increase efficiencies, interoperability, transparency and innovation within many existing government, organizational and business operations. By providing data, content and other resources in CSV, XML and JSON they can be easily used across mobile, web and data implementations. However in other situations there will be a higher need for more advanced interaction with data and content in the form of querying, filtering, transformations as well as the need to secure resources, limiting who has access and to what scale. This is where we start moving beyond just machine readable, and into a truly needing an API.

When it comes to API deployment I would put users into two distinct groups:

  • Technical - You have skills and resources to architect, design, develop and deploy infrastructure, code to meet your API needs
  • Non-Technical - You do not have the resources to assemble and execute an API strategy, making a cloud service an optimal route

APIs are about making critical assets and resources available to technical and non-technical groups.  APIs are often about circumventing some of the ways technology bottlenecks can slow us down.  It is important that there are not just a wealth of cloud services for non-technical folks to deploy APIs, but also a buffet of openly licensed, downloadable tools that anyone can put to use when deploying an API.

Technical

You have some technical resources and the know how (or willingness to learn), and you want an API. Ideally there would be open source tools available for you to download and implement:

  • CSV to API 
  • Database to API
  • Developer Portal 
    • Docs 
    • Code 
    • Support 
  • Registration
  • Authentication
  • Key Management 
  • App Management
  • Billing

These tools would allow you to assemble your own API strategy in the language and platform of your choice. There should be educational materials helping you understand how to implement individually or collectively as a single platform.

Non-Technical

You do not have the technical resources or time to implement your own API Strategy. You need a dead simple, software as a service implementation. You can see examples of this with the latest breed of API service providers, Emergent One, API Spark, and API Engine.

We are just seeing this new breed of API service providers rise to meet the demand of not just API management, but now also API deployment. Making API deployment accessible to anyone, not just developers or companies with necessary resources. This will make the benefits of APIs accessible to the everyday problem owners, who often are restricted by IT bottlenecks or entire lack of IT resources.

Making data and content from a spreadsheet or existing database, machine readable by default or deployed as an API, allowing for more sophisticated interactions, should be as easy as deploying Wordpress for your blog. You should be able to go to a service provider and get exactly the hosting, deployment and management options you desire, or you should be able to download and install on your own infrastructure, giving you the control you desire over storage, hosting and access.

I’m adding a new project area to API Evangelist called I Want An API, where I’ll be working to help define this space, and bring together other people to assist in developing the resources and tools we will all need to easily launch an API.




comments powered by Disqus