9 Red Flags to Look Out for When Selecting an API

Choosing the right API for your new project can play a pivotal role in its success, and it can be difficult, expensive, and time-consuming to extricate it from your project down the line. With this in mind, Deb Haldar recently published a post on A Coder’s Journey highlighting nine red flags to look out for when selecting an API.

Prohibitive or Unclear Licensing Requirements:  

Licensing restrictions can affect the sale and distribution of your product, but they can affect more than that. One of the requirements of open-source APIs licensed under GNU GPL (General Public License) is that you must release the source code of any program that uses it, meaning you’ll have to publish your intellectual property. Companies looking to protect their IP should opt for GNU LGPL (Lesser General Public License) instead as it doesn’t make this demand. Generally speaking, avoid any API on the net that doesn’t include licensing information.

High or Undisclosed Maintenance Fees:

Ongoing subscription fees don’t only apply to cloud-based services. Purchasing software on disk is not always a one-time fee and even purchased APIs may demand annual costs for the duration of use. You may also be asked to pay a fee for each distributed copy, as well as pay for any patches, bug fixes or design changes you ask of the vendor. These all increase the maintenance or operating cost of your software, so find out the details upfront.

Poor Documentation:

Many developers have had bad experiences with poorly documented APIs. While there are ways to overcome undocumented implementation complexities, usually through experimentation or sifting through the source code to determine the correct usage, these methods cost time and effort that could be better spent elsewhere. Select an API with quality documentation.

No Access to Source Code:

While you shouldn’t have to read the source code to understand how the API works (since you have chosen an API with detailed documentation), there are times when access to the source code is vital to understanding and fixing critical issues. Some vendors may deny you access, which shouldn’t be a problem with larger, reputable vendors who provide appropriate support agreements. The lack of source code access becomes a problem when there is a risk of the company going out of business as you’ll have no way to resolve the issues yourself.

Not Thread-safe or Does not Support True Multithreading:

While most software these days is multithreaded, not all clients will require this initially. Even so, they may change their mind somewhere down the line and ask you to provide thread-safety as a feature. If the API you chose is not inherently thread-safe, you could choose to create thread-safe wrapper APIs on top of it, but it won’t perform as well. And take note that incorporating a single-threaded API in an otherwise multithreaded environment will lead to a bottleneck that cannot be resolved.

Not Widely Adopted:

Regardless of whether the API you chose is open source or commercial, at some point, you will need to google information about it to overcome some kind of error. Fewer developers working with the API means fewer discussions on sites like Stack Overflow where people are offering opinions and experiences to help others resolve issues. More users mean more open support, and it also means that the API has been used enough for many of the teething issues to have been hammered out already.

No Dedicated Support Team:  

Open source software maintained by a small team of volunteers in their spare time may often lead to extensive delays when trying to figure out an issue. You may be left on your own to hack a workaround or try to fix the bug yourself, costing you time and effort. Before selecting an API, check the software’s bug filing and resolution history, as well as the frequency of user support requests going through the DL to determine the level of support.

No Backward Compatibility Between Existing Versions:

Developing software with an intended shelf life of over a year will almost certainly require updates for bug fixes or to expose new features. Adopting a more recent version of the API that isn’t backward compatible will lock you into the older version. You could rewrite pieces of your software to generate compatibility with the newer version, but again, this will cost time and effort. Before choosing the API, check the backward compatibility between different versions and avoid providers that have a history of breaking compatibility.

Not Platform Independent:

APIs that rely heavily on platform-specific functionality cannot easily be ported to other platforms. Try to identify an API that uses the standard facilities of a language rather than using vendor- or platform-specific functionalities. This will help you avoid having to rewrite large parts of the system just to migrate to another platform.
 
The choice between going for commercial or open source APIs depends on the project, with each use case having its own specific requirements that will be met by different products. The author admits to preferring commercial APIs from reputable vendors because of the benefits of stability and accountability, as well as the SLAs these options typically have in place. To make your decision, define your specific needs for the project in mind, then try to identify an API that meets those needs without raising any of the issues mentioned in this article.

Original Article

Selecting an API ? Watch out for these 9 Red Flags !

Martin W Brennan Martin W Brennan is a co-founder of ViewPop, the social network that puts the creation of 3D photos and videos in the hands of anyone with a smartphone. For his day job, Martin is a copywriting consultant at We Write Words, learning about the world as he writes about it.

Comments

Comments(1)

pjhinton

I have issues with the publication of this article.  One is technical, and the other is ethical.

From a technical standpoint, this article was written originally to address API issues that arise in deciding to use a third party library in developing a native application, not a web application.

Some issues are common to both situations, but not both.   For example, web API consumers are usually less concerned about access to the API's source code.  Most web APIs govern usage throgh terms of service rather than software licenses.

From an ethical standpoint, I cannot see how publishing an article under one byline and placing a link and acknowledgment for the actual author at the end is fully giving credit where credit is due.

Given that most articles are not read in entirety, most visitors to this page would get the impression that the person in the byline was the author.  Moreover, from a reporting standpoint, the CMS would show an inflated publication count for the person in the by-line.