Complementary APIs for the Oxford Dictionaries API

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 that 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 complement an API. An example of this is with my friends over at the Oxford Dictionary APIs (where the idea of building applications with built-in dictionaries is pretty obvious).

However, the complementary API partnering and usage might not be as obvious, which is something I'm encouraging their team to think more about.

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

API Design

This example is more meta-API, than complementary 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 is 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 an augmented synonym layer that helps 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 keyword 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 another 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 complementary 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 complement and should enrich the solutions being developed on top their platforms.

For a space where integration and interoperability appear 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. On this journey, you should also be looking for complementary APIs for 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!