An Open API Clears Bottlenecks
Back in 2007, Kaltura created a system with an Open API at its core, with both open source and proprietary integrations. Their architecture has always been driven by the same API layer, with all applications—from Kaltura themselves, from their customers and from their partners—built on top of that same set of APIs—no coupling, no back door.
“By maintaining this mandate that everything has to go through the same set of APIs, even when somebody from the open source community wanted to go in and extend the infrastructure and say, ‘Let’s add a new encoder!’ it would be much simpler for them to do because they had to work with the same APIs. They didn’t need to go in to turn the guts of the system upside down just to learn how to write this plug-in. They would just integrate with the same APIs,” Babin said.
Similarly, it’s essential to make your API universal to work with any language. “The ability to touch users in whatever platform they’re using. If you’re using Flash, we’ll have client libraries for you in Flash. If you’re using C#, we’ll having client libraries for you in C#. Or if you’re simply a Linux guy that likes the command line and likes to eat code through Bash, then we’ll have a client for you in Bash,” all with the goal of simplifying the way developers get started with their system.
He says, at the core of this simplification is “reaching your users, wherever they are.”
“You want to encourage innovation around your platform. You want to encourage your users to basically break it down and do whatever they want.”
Babin continued, “Even developers are just like end users.They have their own environments, their own expectations, their own way of learning tools, their own things that they’re used to. So why force them into a custom API that you’ve invented? Why not just reach them with whatever language they are used to.”
Most importantly, you want to make sure you allow your users to do whatever they want with your API, accessing it as soon as they can, as easily as they can.
“You want to encourage innovation around your platform. You want to encourage your users to basically break it down and do whatever they want.” This means that you simplify workflows in a manner in which security still matters a lot, but devops can get into experimenting with right away.
And while API documentation is still essential, Babin would argue that it’s not important to the first few minutes a developer considers your tool.
“Don’t assume people want to read and don’t assume people want to learn. Because they don’t. They don’t have the time, all they want is that there’s a developer somewhere, sitting down, getting commands from his boss, ‘I want this workflow done by tomorrow.’ That developer just wants to go into Google and write the description of the workflow he wants to build and that’s it. Some of them want to just copy-paste it into their application.”
Babin says you need to make this a priority as you build your API. He offers an API console as a great way to do this, as it allows you to select actions and plug in dummy data, just to see how things work without writing code. The idea is that the developer gets to see some general best practices, use cases and examples of your product, without having to go in and read that API documentation early on.
As you dive into the API economy, you need to be sure you are balancing customer success and customization while offering as much automation as possible. If you want to get people first using your tool, do as much of the work for them up front.
How do you use Open APIs for the ultimate developer experience?
Babin gave us one final checklist to make sure you are building a scaleable, incredible user experience:
- Be a platform: Go API-first and build apps on top.
- Eat your own dogfood. Be your own first customer.
- Distributed scale: Design your core with APIs.
- Nobody cares: Make it seamless.
- Nobody reads: Make it literal.
- Remove all barriers to participation (including Sign Here legal formalities.)
- Use the right technology for the situation/user
- Oh and build it so you never break down. Consistency and reliability are always best practices.
Now, tell us below, what should be added to this list? How do you build an API in a way that breaks down barriers to entry and gets developers using it right away?