Thinking in Terms of API Skills and Moving Beyond Just API Resources
As we move toward a more voice-activated and bot-enabled world, it's important to keep in mind the concept of ''skills'' and what they can deliver to users.
Join the DZone community and get the full member experience.Join For Free
The APIs that have seen the greatest adoption across the API space always provide the functionality that developers are needed in their applications. It is either because the platform is already in use by their users (ie. Twitter, Facebook), or just provides the core feature that is required (ie. SMS, Email). There are an unprecedented number of high-value APIs out there, but I think many API providers still struggle when it comes to defining them in a way that speaks to the needs that web, mobile, and device app developers will be needing.
I have explored this topic before, discussing the importance of exposing the meaningful skills our APIs possess for use in the next generation of messaging and voice apps, as well as asking whether or not our APIs have the skills they need in a voice and bot enabled world. I am not 100% behind the concept that voice and bots are the future, but I am 100% behind defining our API resources in a way that immediately delivers value like they are doing in these environments.
The approach used by Alexa, when it comes to developing "skills" is an important concept for other API providers to consider. Even if you aren't targeting voice enablement with your APIs, the model provides many positive characteristics you should be emulating in your API design, helping you deliver more meaningful APIs. For me, thinking in terms of the skills that your APIs should be enabling better reflects the API journey, where we move beyond just database and other very technical resources, and providing the meaningful skills developers need for success, and end-users (AKA humans) are desiring.
Published at DZone with permission of Kin Lane, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.