Tips for Evaluating APIs as Part of the Build vs Buy Strategy

Donna DeMarco, Co-Founder & VP, Viddler

Donna DeMarco, Co-Founder & VP, Viddler

Application Programming Interface (API) code has been around for decades, allowing developers to integrate functionality within applications, as well as share data between applications. While APIs are a powerful tool for developers, they also influence the build vs buy decision at the business level. Are there criteria when evaluating a new product for the enterprise or business? How can APIs be leveraged to provide faster time to market, higher quality products, and lower maintenance costs?

When I began programming in the early 1980s, we wrote in Basic Assembly Language and created low level routines to interface to other computers. As time progressed, common libraries of these routines were created and used instead of rewriting the interface code again and again. Early on, I learned that reusing existing code, (sometimes known as “stealing”) is good in software engineering. But in order to “steal” a piece of code, it needed to be well documented with an easy to understand interface.

As systems grew in complexity and sophistication, the size and complexity of how to communicate between systems also grew. Over time, the routines expanded from “get and put data” to many more specific queries and function. A consistent, standard method of defining and managing these routines, and their re-use was needed-Application Programming Interfaces (APIs) as a process and toolset were born.

Today, APIs are handshakes between applications and provide the piece parts to build an application. Think of the question you are asked when you install a mobile app: “Allow this app to access your phone’s camera?” The app developer did not write code to control the camera; they integrated an API that interfaces to the camera. The power of APIs allows developers to quickly build applications using piece parts to assemble.

APIs have grown from interfacing between computers to interfacing between whole systems and applications. Similarly, “stealing” has grown from re-using code at the developer’s level, to integrating whole applications at the product level. This allows the build-vs-buy decision to be applied at the product level. After defining the requirements for a product, an evaluation is needed to determine how many piece parts already exist, and how many need to be developed.

If you picture an organization chart to represent the hierarchy of product requirements, the upper management functions usually need to be developed in-house. These are the “secret sauce” capabilities that make the product unique, addressing the heart of the problem being solved by the product.

While the lower level “worker bee” functions are good candidates for a buy decision.

When evaluating vendors’ applications to be integrated into your product via APIs, there are a number of factors to consider. Once the initial business level evaluation is complete and the vendor’s application has qualified as a solution fit, the next step is to determine if the API is sturdy enough to support the integration. There are a number of factors to consider when evaluating an API:

What to look for in a robust API:

1.APIs should exist for all application features

Using the camera example, if the camera API package allowed you to take a picture, but not save the picture, the API would obviously be incomplete. A good application will have the API structure architected in from the beginning, not bolted on as an afterthought. All application functionality should have a corresponding API available. As the application adds functionality, an API is added to access that functionality. The APIs can be segmented by application functionality: content management, user management, etc., so that external access to the APIs can be controlled and monitored.

2.APIs should also include wrappers

In addition to the API, code templates, called wrappers, should be available for common languages (ruby gem, php library, JavaScript, etc.) using the standard interface protocols. These wrappers make it easy for developers to integrate the APIs as they are code snippets in the particular language that show how to use the APIs.

3.Comprehensive documentation

In addition to the basic documentation on how to use the APIs, there should be working code examples, error handling explanations, current status of API versions and wrappers, any known limitations, browsers and devices supported – everything the developer needs to integrate the APIs successfully. The documentation must be kept current and updated periodically.

4.Testing Environment

During the development phase, a test environment allows the developer to test the application interface without using the production version. This is usually in the form of pointing the product to a vendor’s staging environment. A bonus is an interactive test tool at the API level where the developer enters the API call and the response is automatically displayed.

5.Humans to talk to

While superior documentation and a test environment are very helpful, a real live person is even better. The API support staff should be available through all phases, from on-boarding of the API application, through development, testing, and launch. A corollary to this is open communication with the vendor for roadmap plans, maintenance updates, etc. to plan for product upgrades.

To give an example, the interactive video company, Viddler, averages 25 million API calls per day. In addition to providing clients access to the Viddler APIs, the platform “eats its own dog food,” meaning all Viddler applications are built on Viddler’s APIs. Without implementing the tips listed above, Viddler would fail as an API provider. These practices add accountability by the Viddler development team to ensure a robust API environment.

By using APIs, you extend the capability of your development team. The key is to ensure the vendor, application, and APIs all exceed your expectations.