APIs are everywhere and fast-becoming the life-blood of the modern web. They are powerful tools, especially for a start-up.
But navigating today's API landscape, with its hundreds of thousands of choices available can be daunting. Knowing the right things to consider when selecting a Travel API to meet the needs of your product and beginning the build is important. Here, in the first of a two-part series of articles, we ask a panel of experts their top tips to consider when selecting an API to work with your product.
1: Think of the end user at all times
At the API selection stage, you are met with a vast array of choice. As Bill Doerrfeld, Editor in Chief at Nordic APIs puts it," you are a kid at a candy shop that needs to be scrupulous in vetting these integrations”.
The end-user: the customer or individuals that will ultimately consume the content of your API as part of your product, must however, remain front of mind. Doerrfeld suggests checking any potentials APIs to make sure near 100% run-time is guaranteed and to establish where operational status is communicated.
Doerrfeld also recommends checking that the API you’re considering has good error response handing, and explore whether the product has method calls structured correctly.
If any of the above components are sub-par, it will be detrimental to the end-user. Keeping your user in focus is also a sentiment which is echoed by Martin W. Brennan, tech commentator at Programmable Web and Founder of start-ups The Pratley Company and WeWriteWords:
2: Consider the documentation
Another crucial element pre-build stage is documentation. To implement an API to work best for your product, you’ll need to make sure its supported by quality literature – something which is echoed by all of our experts. Never underestimate the power of quality support documents!
Tiff Burns, Founder of Apple's 'Best of 2015' app LuckyTrip comments, "Having simple, clear documentation helps developers speed up the development process and focus on building a great product".
Doerrfield suggests that documentation must be “lucid and housed within an easily navigable developer portal”. Documentation should be easy to find, follow and refer back to, as you will inevitably need to.
He also suggests checking to see if there are SDKs or Libraries available to extend your functionality to your own unique language.
For Brennan, documentation should be flexible and adaptable enough to equip you with what you need should extra functionality be added to the API:
“Don’t forget to monitor that documentation for changes to API functionalities. Find out about API changes from the documentation before they go live, and make sure your product is prepared.”
Thanks to our experts for their input and advice: