The software world has moved in many ways towards the idea of modularity rather than the archetypal monolith — services and systems are continually developed in chunks rather than as a single system. This has spilled over into many aspects of the API space, and represents a powerful opportunity for developers to not only simplify the development cycle, but to leverage modularity to make their own offerings more powerful.

When we discuss the idea of leveraging public APIs for our own system, the topic is often met with the concept of dependence. Using a public API should not be viewed as a crutch, however, but instead a tool that makes the fundamental function more powerful. The modern developer can use public APIs for better systems development and implementation, enabling truly rewarding and powerful end results.

Today, we’re going to take a look at some popular public APIs, some use cases that can benefit from their integration and usage, and general concepts regarding best practices for using these systems.

Use Case – Biometric Authentication

Let’s consider a theoretical API to see how this might work. Let’s say that we’re developing an API whose primary function is to take a picture using the camera on a mobile device, authenticating the user using biometric data, and allowing them to access bank payment data for mobile e-payments.

We could very easily code certain portions of this — ePayments have been well-handled with solutions like ApplePay, and the methodologies are rather well known. That being said, though, the biometric half of the equation is far more difficult to code and implement.

Thankfully, there are quite a few choices for public APIs that can fulfill this purpose. An example is the SkyBiometry Face Detection and Recognition API, an API that utilizes advanced facial scanning to identify users from a variety of angles. By tying into this API, not only do we get to skip the entirety of that particular development cycle, we get to use some features we may not have initially planned for.

As an example, the SkyBiometry API also has the power to register the gender of a user as well as whether or not they’re wearing sunglasses or otherwise obfuscating part of their face. This kind of functionality may not have been initially planned, so having it be part of the API we’re tying into adds additional data and could increase security.

This sort of security-oriented API leveraging is present in other solutions as well. One such solution is the Sense-IoT storage API, which collects data from devices in the Internet of Things and stores it in the cloud.

Let’s say we want to extend our ePayment service out to NFC (near field communication) devices such as those in Asia utilizing the FeliCa standard. By integrating a tag storage system, we can read tags on payment devices such as rail payment cards and other wireless payment solutions, and with proper agreements with vendors, handle these payments on a single wireless device.

This functionality could then be tied to the biometric service, utilizing facial recognition to authenticate and authorize access to secure resources that might use NFC technology, such as those in secure facilities and education.

What we’ve fundamentally built, then, is not only a payment application, but an identity management application with a payment handler tied directly into it. We’ve combined IDs and payments into a single service — that’s like combining a driver’s license, access device, and payment card into a single system, all from a barebones system tying into external APIs.

Brand Continuity

API leveraging isn’t always for functionality, either. APIs can be integrated for continuity over social platforms, allowing for pre-defined, consistent branding across a variety of services.

Let’s say we’re hot on the heels of selling our old ePayments system, and are now trying to create a new one — one that can help music fans find concerts, pay for tickets, and share reviews of venues. While we want all of this functionality, we do want to keep the API rather lean, as opposed to developing an entire ecosystem. Knowing how effective your payment API was, you can easily tie into it.

As you’re developing the ticketing system, you consider how exactly you’re going to handle the social media aspect of reviewing venues. It’s obvious to your team that half the problem has already been handled — providers such as Yelp! have public APIs that can populate a rating system. These results can be filtered easily to only display music venues and concert halls. Likewise, the Twitter API could be used to tie in hashtags for certain bands and venues to connect users of the application. Leveraging these platforms not only makes your application better, it reduces the overall development cost by quite a wide margin.

With all these use cases, essentially what we’re trying to avoid is re-inventing the wheel. If there are solutions in the API space that already do what you need it to do, there’s no sense in wasting development time and energy.

Other Benefits to Using Public APIs

There are quite a few benefits to leveraging public APIs. We’ve highlighted a few throughout this piece, but the value is still understated.

First and foremost, as has been previously stated, using pre-designed APIs reduces your time and economic investment. More than that, however, it shifts the continuing cost from the initial developer to the API provider.

If a company were to develop an API from the ground up, every iteration, integration, and revision would necessarily come with a cost of time and economy to test and implement. This responsibility is huge, and can be a drag for small companies and developers.

When leveraging an API, though, you shift some responsibility to the API provider. For instance, tying into the PayPal API moves the responsibility of payment maintenance and new payment methodology adoption from the API developer to the PayPal team, a team backed by more capital and manpower than many developers could hope or dream to achieve.

Additionally, integrating with a public API also provides a sense of continuity of service to your users. Most users who partake in eCommerce are likely familiar with PayPal and other payment vendors, so seeing that badge on your website and an integration into your API can be a boost to credibility as well.

As part of this, the API provider also gains a continuity of functionality. System functions developed internally places all the developer’s eggs in the same basket — if one piece fails, every bit of functionality could fail. By tying into a public API, if the authentication feature fails, scheduled payments will not, as the payment API and authentication API are separated.

Leveraging as a Business Strategy

While we’ve been talking extensively about using parts of a public API to increase the functionality of our API, we’ve not talked much about the main benefit of API leveraging — increased business value. As we’ve said before, many businesses rely on APIs for survival. Consider this — developing an API, especially in a space where many APIs already provide some functionality, is a difficult proposition. Acquiring user share is even more difficult.

Thankfully, tying into a public service can provide a huge benefit to initial system development. TripAdvisor is a great example of this — a service with over 300 million users, allowing partners to tie into their huge user database. Integrating their API not only grants the system a huge boost in initial user reach, but in business and brand value as well. This reach also increases the breadth of the system itself. By tying into more services, your service becomes affiliated with a larger market, and if designed well, could become ubiquitous within that economy.

Data Generation

Not all of the benefits are in the functionality of business or the API that the business relies on — some of it is in the pure data generation potential itself. Valuable data comes in many forms:

• The United States Government provides millions of datapoints culled from its open data initiative concerning crime, racial makeup, population centering, and other related datasets.
• The European Union has the same approach to much of their data, providing an open data solution via an official portal that is invaluable to business strategy and planning.
• Twitter’s API provides access to over 7 thousand tweets per second, sortable by hashtag, relevance, user account, and more.

All of this data is valuable, and tying into the APIs that generate them can ease development requirements considerably. Getting this data from web-scraping or in hand-coded form would be difficult and lead to inconsistent behaviors. Tying into these APIs, rather, would be a low cost alternative, and would ultimately result in a similar product with almost no investment.

Reduction of Time Cost

When we look at what makes a business effective in their market, one of those variables is time. When we consider the impact of time on APIs, we’re really look at two variables — time to develop, and time to market.

Poorly timed launches and integrations can do more to hurt a fledgling API or app than any amount of bad press or shoddy implementation. If a product has gotten to market as your competitor, you can expect your development cost, your marketing cost, and additional costs to multiply.

Therein lies another benefit of integrating with public APIs — if you have an issue, chances are the solution has already been found for it. When leveraging a public API, you’re not working against a competitor — you’re using their success as a magnifier of your own potential, leaving time for additional development tracts, further testing, and even ideation.

Assume you’re making a photo editing application that will use an API to bring photos from a variety of sources. If developed independently, you have a single resource to pull from — the user manually authorizing upload. In order to have a public repository of user images, you would have to code an entire database with authorization, authentication, sorting algorithms, and more.

In a market competition frame, you’re losing time, and fast — and if “first to market” is not a concern, you’re also using precious time that could be repositioned for testing your end result. However, if you tied into public APIs from Getty Images, iStock, Adobe Stock Photos, or other services, you’re guaranteeing high quantity content access, negating the cost of “first to market” by pairing with someone already there, and reducing the time to develop the feature in question.

By doing this, the only variation between your offering and those of your competitors is then your product itself and the way in which it’s presented, not whether your timing was good or not. APIs can slyly negate the old adage of “first to market is the winner” by leveraging the success of others.

Conclusion: APIs Multiply Innovation

Finally, one of the huge benefits of leveraging an external API is the idea of innovation multiplication. Innovation is an interesting thing — it depends equally on experience, random strokes of genius, and educated guesses on where the industry is heading.

Though innovation sometimes relies on chance, it can be influenced by some factors; one of which is the number of people innovating. By tying into external APIs and using their own genius to extend your development activities, you’re essentially doubling, tripling, sometimes quadrupling your research and development team without a massive economic investment.

In the most simple terms, leveraging an API can make your system “better”. Better in the sense that your innovation can be quicker, more complete, and more interesting. Better in the idea that the system as a whole — from inspiration to iteration — is streamlined and improved.

What this takes, however, is foresight into exactly what systems can be outsourced in the initial stages of development. Taking the right approach can grant all of those benefits — taking the wrong approach could make for a meddled, confusing result.

While something could be said for developing in house, especially for vital internal-facing architectures, the fact is that the API space has matured, signaling more reliable integrations than ever before. With roughly 16 years of solid innovation and creation within the realm of public web APIs, the idea that we should eschew all of that effort is mislead.