API Embeddables With Skills and Intent
11 Oct 2016
I am seeing some renewed interest and discussion around API driven embeddable(s)--an area of my API research that has been going on for years, focusing on buttons, badges, and widgets, but is something that I'm seeing continued investment in from API providers lately. To help fuel the innovation that is already occurring, I figured I'd contribute with my API thoughts extracted from across the bot and voice API landscape.
As I monitor the bot community growing out of the Slack platform, the voice API integration emerging from the Alexa development community, and read news about Google's latest push into the space, I'm thinking about how APIs are being used to define the intents, skills, and actions that are driving these bot and voice implementations. I am also processing this intersection with the latest release of Push by Zapier. All of this about delivering the meaningful API responses, to where the end users desire--in their browser, their chat, or voice enablement in the business and home.
I am not always the biggest fan of voice and bot enabled scenarios, but I do think they provide us with some interesting constraints on API design. I'm hoping that some of these constraints can further be applied to legacy approaches of API deployment. Voice and bots are nothing new, but the current wave of evolution, in this time of abundant API-driven data, content, and algorithms, hold a lot of potential. This is why I spend so much time looking at so many different areas, is that the cross-pollination opportunities are sometimes the most interesting ones, and are often the ones that folks can't always see from the individual verticals where they are putting APIs to work.