Complimentary APIs For The Oxford Dictionaries API

by Kin Lane, API Evangelist Twitter LinkedIn Github Email

Many API providers I meet have the "build it and they will come" mentality, thinking that if they build an API, developers will come and use it. It does happen, but many APIs only have so many direct uses, and will have a limited number of resulting implementations. This is one of the reasons I recommend companies do APIs in the first place, to get beyond the obvious and direct implementations, and incentivize entirely new applications that a provider may not have considered.

Developing innovative applications an API provider may not have considered is the primary focus of companies I talk to, but only a handful have begun thinking about the other APIs that are out there that might compliment an API. An example of this is with my friends over at the Oxford Dictionary APIs, where building applicaitons with built-in dictionaries is pretty obvious. However, the complimentary API partnering and usage might not be as obvious, something I'm encouraging their team to think more about.

What are some examples of complimentary APIs for the Oxford Dictionaries API?

  • API Design - This example is more meta API, than complimentary API, but I'd like to see more API design tooling to begin to use dictionaries as part of their GUI and IDE interfaces. Providing more structure to the way we design our APIs, helping ensure that the design of leading APIs are more intuitive, and coherent--achieving a less technical interface, and something that speaks to humans.
  • Machine Learning - I'm using a number of machine learning APIs to accomplish a variety of business tasks from object recognition in images, to text and language pattern recognition in content I produce or curate. There are a number of opportunities to extend the responses I get back from these APIs using a dictionary, helping increase the reach of the machine learning services I employ, and making them more effective and meaningful in my business operations.
  • Search - I use the Algolia API to build a variety of search indexes for the API space, helping me curate and recall a variety of information that I track on as part of my API monitoring. I'm considering building a augmented synonym layer tha thelps me search for terms, then expand those searches based upon suggestions from the Oxford Dictionaries API. I'm looking to augment and enrich the Algolia search capabilities with the suggestions from the dictionary API, expanding beyond any single key word or phrase I identify relevant to any industry or topic being served by the API sector.
  • Bots - If you are going to build convincing bots using the Slack or Facebook APIs you will need a robust vocabulary to work with. You won't just need a single downloaded and stored dictionary, you will need one like the Oxford Dictionaries API that evolves and changes with the world around us to enrich your bot's presence. 
  • Voice - Similar to bots, if you are going to deliver a robust voice interface via Alexa, or other voice enabled platform, you will need a rich dictionary to work from. Similar to how I'm expanding and enriching the other suggestions listed above, a dictionary layer will expand on how you will be able to interpret the text that is derived from each voice interface engagement.

These are just a couple examples of how one API could provide complimentary features to other APIs out there. It is important for API providers to be reaching out to other API providers and their communities when evangelizing their own APIs. Sure, you should be incentivizing developers to build applications on top of your APIs, but your definition of "application" should include other APIs that your resources compliment, and enrich the solutions being developed on top their platforms.

For a space where integration and interoperability appears to be priority number one, the API sector is notoriously closed, and many API providers I meet have their blinders on. As an API provider you should always be studying the rest of the API sector, looking for good examples to follow, as well as bad examples to avoid--similar to what I do as the API Evangelist. Along this journey you should also be looking for complimentary APIs to your platform, and vice versa. Think of SendGrid and Twilio as an example--email, SMS, and voice all go together very well, and their communities significantly overlap, providing the makings for a ripe partnership.

What are a couple of existing APIs that your APIs complement? This is your homework assignment for the week! ;-)