This blog post is about open vs private or closed APIs. For the web service specification, see OpenAPI Specification.
A few months ago I wrote a blog post about how important it is to make dev teams at FAIRTIQ independent and specifically how we leveraged Kafka to address a facet of it. In this blog post I’m looking at the same topic with a broader view: using open APIs to make companies independent while still having them benefit from one another. To illustrate it, I created an app that connects FAIRTIQ and Slack.
You’ve experienced it, the symbiosis
Over the past decade more and more companies have allowed developers to build applications on top of their platform and data. You are probably familiar with the “Sign in with Google” button that provides a 1-click registration to your favourite website using your Google account data, or the “Impress your friends” in your awesome video game’s leaderboard, which would make all your Facebook buddies jealous about your new high score.
This kind of feature is possible thanks to open APIs. A company makes some data and actions publicly available for any developer to use in their own applications (in contrast to closed or private APIs). Generally, that benefits both parties. In the examples above, Google and Facebook get more accounts or activity on their services, whereas the developers can leverage the platforms to get more visibility or provide simplified user registration.
Open APIs allow platform providers to leverage the creativity of an ever growing developer community to come up with innovative applications that add value to their core business without investing directly in the development of these.
When any developer can use an open API to make cool things within our accounts, they can also do things which are less cool, all the way down to malicious. The data privacy question comes naturally to our mind. It turns out that the rules regarding who can do what and see what are set by the platform provider, i.e. the one providing the open API, holding the data and enabling the predefined actions. In most cases there is an authorisation flow, where the user grants the permission for instance to Acme inc to post on their Facebook feed on their behalf. Once the permission is granted, it remains valid until the user explicitly revoked it.
Open APIs and FAIRTIQ
Whereas FAIRTIQ provides open APIs for the public transport organisations (to connect their pricing systems for instance) it doesn’t provide a user-facing open API as of now. Let’s see how it could look like in a very simple form. An open API can be seen as a set of data to read, events to be notified about and actions to be performed.
One could argue that this is rather limited. However the full power comes when combined with other services or open APIs. Let’s say you want to create an app called “Travel with me buddy”. You could ask the user’s permission to access their FAIRTIQ check-in information and their Facebook friends. When two friends check in at the same time and place, you would send both a notification. As an event organiser, you could promote public transport to join the venue. You’d connect your event app to FAIRTIQ so that participants get credits to spend on-site based on how many kilometers they travelled with FAIRTIQ. Or as a home hacker, you’d make sure your vacuum cleaner robot starts worrying about your floors as soon as you leave your home and check-in.
The possibilities are endless. Some of them are home hacks and fun whereas others can be large scale revenue generating businesses. Given the potential, I want people at FAIRTIQ to start thinking “open API”. It’s a mindset. Something to have in the back of your head anytime regardless whether you are a developer, a sales person or a product designer. In order to make it more tangible and sparkle some ideas, I created the Commuting bot.
Introducing the Commuting bot
The Commuting bot is an app that automatically changes an employee's Slack status to “Commuting” whenever they are checked in with FAIRTIQ and restores it to whatever it was before when they check out. It leverages Slack’s open API and FAIRTIQ’s inexistant open API (an internal simulation).
For this to work, the Commuting bot must obtain the user’s permission to be notified by FAIRTIQ whenever they check in and out, and from Slack to read and change their status. On the FAIRTIQ side, we do not support this authorisation model yet as we don’t provide an open API, so I hard coded it. On Slack, this is achieved by setting up a Slack App and setting the appropriate scopes.
It’s worth noting that the Slack app contains no app logic. It’s only a way to request the appropriate permissions to the Slack user when they will install the Commuting bot. I created a basic web interface that allows FAIRTIQ employees to connect their Slack account to their FAIRTIQ account. After authenticating with FAIRTIQ and pressing “Connect” they are redirected to a page provided by Slack where they authorise the Commuting bot to edit their Slack profile on their behalf.
From now on, the Commuting bot monitors the check in and checkout events on FAIRTIQ and adjusts the user’s Slack status in consequence. Behind the scenes, when the user grants permission to edit their Slack status, the Commuting bot obtains a token that allows it to act on Slack on the user’s behalf (as if it was the user themselves). This authorisation remains until the token is revoked. That can be done by clicking “Disconnect” in the Commuting bot or by uninstalling the Commuting bot app from Slack.
And it scales
Both companies FAIRTIQ and Slack most likely don’t care that much about Michel’s Commuting bot. That said, they also haven’t invested a single penny in it*. They only provided an open API that millions of Michels can use to innovate and/or serve their own business needs. Surely, providing an open API has a cost, however it’s mostly independent from the number of use cases that run on it. Make the open API once, let millions use it.
There are actually operational costs when running an open API, which are dependent on the usage, but they are usually marginal, provided that you have measures in place to prevent abuse (e.g. a developer sending billions of requests). For large scale usage, such APIs can also be monetised.
* Ok, I’m an employee of FAIRTIQ so that wasn’t completely free for us, but assume I wasn’t.
Conclusion
The benefits for both the open API provider and the consumer depend a lot on the use case being developed. Usually it’s a win-win situation: both parties mind their own business and on top they help each other without specifically investing in doing that. The open API provider leverages worldwide innovation for free, while at the same time unlocking new business opportunities for all the others. These new use cases, when successful, generally have a positive direct or indirect impact on the open API provider’s business.
Open doesn’t necessarily mean free. It means it’s not restricted to specific people or companies. An open API can be monetised if it makes sense to do so. Nevertheless, it must be done very carefully as it could easily defeat the purpose if it becomes a barrier to adoption. Freemium models (pay only if you make money with it) can be adequate.
Finally, open APIs are a great way to make systems interoperable. This becomes increasingly important, as systems grow in complexity and size. A big fat system operated by a single company will age much faster than a composition of multiple smaller, interoperable systems, each maintained by another specialised company.
Ah, and the title’s question? Well, now you know…
Share