Do You Need an API?

API stands for ‘Application Programming Interface’ and as the name implies, creating one is a technical process. This article will talk very little about how to create an API as there are a myriad of methods to undertake that. This article aims to focus on the business side of APIs and supply advice for non-technical folk.

An API is a set of functionality and instructions to allow other software access to services or information you offer. An API is typically (should be) written following standard patterns and can be free or monetized in several ways.

Who Has Them?

Lets start with some examples to better illustrate what an API is and how they are used.

Most online services of any worth

These examples are obvious ones, but worth starting with to clarify the concept. APIs are part of the core business of companies such as Google, SalesForce, Yelp and Twitter. All of these companies provide access to the information they posses through APIs that are widely used by other businesses and their developers in a variety of applications. All of these companies offer varying payment levels depending on the quality or quantity of access you require, from free upwards.

Government, civic and science organizations

These are not conventional businesses but this sector has seen such a recent growth in API adoption it seemed worthy of mention. Governments across the world, from local to federal have started releasing certain data sets to the public through APIs. There is mixed opinion on how effective and useful some of these data sets have been, but it is a brave first step and some have resulted in incredible insights and applications.

Other examples

If you’re not a predominately online business or in the Civic space, should you still consider an API? They are mainly suited to information and knowledge based businesses. For example, I am currently ‘archiving’ a charity I used to run in Melbourne so that the information and resources we gathered can be utilized by others and aren’t wasted. As part of this process we will provide an API so others can aggregate and utilize our content. We will be charging to access certain items of content, but most will be freely available. Whilst the delivery is all online, it draws on our offline experiences.

Increasingly hardware businesses will utilize more APIs. There is still software powering the hardware, but creating hardware with API access will mean that your products will have more potential and a longer life.

Justification

You may be a forward thinking individual inside of an organizational structure that doesn’t share your views. How can you convince others around you that having an API may be good for your business? Here are some positives to mention and some negatives to prepare yourself to hear.

Positives

Converting competitors into partners

If you are the first in your market with API access then you have the potential to bring your competitors on board by utilizing your data and resources in their products.

Unexpected (positive) results

Giving your users the ability to create some of their own specific tools has the potential of resulting in some unexpected new tools that you would never have had the inspiration or time to create yourself.

Scaling market reach

Both of the above points will help broaden your potential reach with little work and investment, perhaps only requiring better infrastructure.

Empowering users

Trusting your users and giving them extra value beyond a core product helps encourage a strong feeling of loyalty. This increase of loyalty gives your company a small advantage over competition.

Negatives

Do you really need an API?

APIs are the past 18 months’ ‘cloud service’; everyone has heard of them and wants one without really knowing why. Thus the temptation is to jump on board to keep up to date. Do you really need to? Is there any point? Creating and maintaining an API will involve extra staff and resources, do you have them available?

Security

If implemented correctly an API shouldn’t open you to any more security breaches than your normal online presence. However, the more you open your organisation the more you open yourself to individuals (or automated systems) that want to find a way to exploit these partially open doors.

There are several solutions to this problem, based on best practices:

Secure API access behind a unique method of identifying a user, even if you are offering access for free.
Consider hosting your API service on a separate server to the data it is accessing.
If you are offering a level of API access that allows users to also add or update your information, this process will need to be well protected from harmful attacks (called ‘injections’).
Protect yourself against Denial of Service (DOS) attacks caused by an orchestrated intention to overload your systems.

Opening yourself to criticism

With certain data sets (especially civic) you have the potential to having your data analysis and critiqued. This isn’t always a negative, feedback can be constructive and useful. However, opening the floodgates can be daunting and draining.

Another potential point of criticism is what others choose to do with your services or data. This issue has hit several high profile targets recently, for example Snapchat’s recent data breach was due to a third party accessing the service in a method that was in breach of Terms of Service. I’m sure we all know that just because we tell people they can’t do something, doesn’t mean they won’t try.

Implementing an API

As with any other technical (or non-technical) project, before you begin any implementation, plan, plan and plan some more. Set out your strategy, what you want to achieve and why. Set out what you will give people access to and why they might want to access it. Document what you are setting out to accomplish, this will help explain things to others later and set the basis for documentation for implementation.

This isn’t a technical article, so I won’t go into too much detail on the actual implementation, however, there is one rule of thumb worth following:

Don’t reinvent the wheel.

There are standards for API design and management, whether you decide to create your own or use a service that will create one for you. These standards are tested, understandable by those who will use them and will help prevent some of the negatives mentioned above.

Conclusion

This article has touched the surface of API design and implementation, my main parting words of wisdom are not new. Ensure that you undertake any project for the right reasons.

Here are some resources I recommend for further investigation: