There are more choices than ever when it comes to APIs–and that’s a good thing. But it also means you’ll need a strategic plan for choosing the right API solution.
Two questions I’ve found can help guide that decision:
- What problem are you trying to solve right now?
- What functionality will you need in the next five to 10 years?
Once you’re clear on the answers, you can evaluate API solutions based on the following five criteria to choose the one best suited to your needs.
Performance
In a highly competitive global market, it’s not enough to have reliable uptime. Speed also matters–a lot. A site that loads in one second has a conversion rate three times higher than one that loads in five seconds.
To accommodate current customer expectations for page speed, API response time should be no greater than 90 milliseconds. One way to blazing-fast API speeds is to take a client-side approach where data is delivered to an edge node of a CDN network instead of stored on a server somewhere in your data center.
But let’s return for a minute to the first question I introduced above: What problem are you trying to solve? If you’re an online retailer, you want your site to load fast so your customers don’t click away and you want everything on it to be accurate–for example, if an item sells out while a customer is browsing, they shouldn’t be able to put it in their cart.
Not every function requires the same level of speed. Product description content, for example, is mostly static, while inventory is not. So content delivered by your CMS’s API may not require the same speed as data from a transaction engine.
While high performance is important for every API you use, the actual performance benchmarks each one needs to meet vary based on function and on the end-user problem you’re solving.
Documentation
Thorough documentation is a must-have for any API solution you adopt. Without thorough documentation, your team will be forced to figure out how to use the API via trial and error supplemented with time-consuming support interactions. Strong documentation lets developers use APIs more effectively and, ultimately, ship products to market faster.
But even among providers that offer thorough documentation, there are more and less helpful varieties. I’ve read plenty of documentation, for example, that is written with the assumption that the person reading it already understands how the API works. This makes it harder for newer developers to learn and understand the capabilities of an API.
As you consider providers, look for those with documentation written for someone who is totally new to the API–which you and your team will almost certainly be. As a stylistic guide, look to documentation from Mozilla, MDM and W3 schools, which I think do an excellent job of communicating for non-experts.
To gauge the helpfulness of a potential provider’s documentation, I recommend having your team read some of it and asking the partner team how often they update it. A best-case scenario is that they consider documentation an ongoing project that will never be complete.
Security
Security is pretty self-explanatory, so I won’t spend a ton of time on it here. Any API provider should offer robust security to ensure that the API cannot be used nefariously by bad actors or hacked to expose sensitive information. REST APIs almost always follow standards like 0Auth and TLS to maintain security. It’s worth looking at how the API you’re using describes its security practice.
Flexibility and Extensibility
Your team should have the freedom to create whatever they want with the APIs you use, meaning they shouldn’t be hampered by roadblocks in the API’s design. This freedom to create should exist in all aspects of the API: It should let your team create whatever customer experiences they can dream up, and it should let you manage back-end information in whatever way makes sense for your organization.
In other words, an API solution should be well-defined but should not define everything you can do with it.
Pricing Model
The final piece to take into consideration is the API’s pricing model, by which I mean not only its actual cost but also the way the provider charges to use its service.
For example, does it charge by order? By bandwidth? By number of records? Again, this comes back to the problem you’re trying to solve: If you have a lot of requests to make, for example, don’t choose a service that restricts requests per minute.
And even if a pricing model works for your business today, will it work as you scale? This question brings me to my final thought.
API Solutions Should Make it Easy to Grow and Evolve
I started this piece with two key questions to guide the process of choosing API providers: What problem are you solving and where is your business going?
If you’re exploring APIs as part of a replatforming project, there’s a good chance you chose a platform 10 years ago that could do everything–but that can’t keep up with evolving customer expectations or that restricts your team’s creativity today. The APIs you choose should let you meet current needs and make it easy to make changes–including swapping one API provider for another–as your needs evolve.
In other words, when you choose the right API solutions, you should never need to do another replatform.
