Go back to blog listing

How Adopting an External API is Like Purchasing a Used Car

CertifiedServicesCM Crossroads recently published this API Testing article by Parasoft's Wayne Ariola and Cynthia Dunlop....

Imagine you're looking to get a used car for your teenage daughter. Ideally, a trusted friend or relative is willing to give you a great deal on a hand-me-down that you know they've treated with care. You see if your daughter likes it, then give it a test drive. If it seems like a good fit, you're all set.

Now imagine that nobody you trust is looking to unload a car right now. Are you comfortable putting your daughter in a car that you found from an independent seller on Craigslist? Or would you rest easier if you set her up with a certified preowned vehicle—something that passed a reputable dealer's one hundred fifty-point quality assurance inspection and was backed with a five-year bumper-to-bumper warranty and roadside assistance?

With service-oriented architecture (SOA), as with the hand-me-down car from a close friend or relative, the element of trust is key. Because you're familiar with the "supplier," you're not so worried about the quality of the product. You can reasonably assume that certain standards have been met, and you're comfortable moving forward without extensive vetting.

On the other hand, consuming external application programming interfaces (APIs) is more like purchasing a used car on the open market. With limited insight into its integrity (beyond API user ratings, which you might say function like Carfax reports), you can't really know what condition it's in or predict how reliably it will be able to meet your needs over time. Before you bring it into your "family," it's quite prudent to want to know how it stands up under rigorous testing.

Unfortunately for anyone using today's composite applications, most software development leaders aren't nearly as cautious about vetting the APIs their applications consume as they are about scrutinizing their personal consumer purchases. In fact, surprisingly few organizations today even think about testing the APIs they rely upon to drive their business-critical processes. This issue becomes a real challenge in organizations that embrace agile development and DevOps, where new features are developed rapidly and sometimes delivered continuously throughout the day...

SOA: "Trust but Verify"

With SOA, the services you consume are typically developed within your organization or by a close business partner. You can reasonably assume that a service was developed according to standards similar to your own and was subject to comparable quality control measures. Moreover, in the event that it fails, you know who to go running to, and you can reasonably expect that problems will be resolved in a timely manner. Also, there is at least some chance (albeit slight) that if the service producer decides to make substantial updates to the services you are relying on, they might actually let you know.

How does this translate to testing? As long as you can trust that the service meets reasonable quality expectations, you can focus on verifying the service in the context of your end-to-end business transaction.

APIs Require Substantiated Integrity

When you adopt APIs that are produced and managed outside your organization's "geopolitical control," you typically have no visibility into how solidly the exposed services were built—or when and how they are evolving. If an API fails, quite likely your hands will be tied. Unless the API was backed by a service-level agreement, you probably have little recourse. Moreover, because the failure is manifesting itself via your application, you're ultimately going to be the one to shoulder the blame and suffer the consequences.

On top of your lack of insight into the quality and evolution of external APIs, as well as your limited ability to act if there is a failure, there are also risks associated with integrating exposed APIs into your applications... 

Visit CM Crossroads to read the remainder of the article. 

[White Paper] API Testing Myths

APITestingInforgraphic

As we enter "The API Economy," the risks associated with API failure undeniably have broader business impacts. It is now more important than ever to ensure that the APIs you produce and consume continuously deliver the expected level of security, reliability, functionality, and performance.

With so much at stake, there's no better time than the present to examine the reality behind some of the most common API testing myths emerging across the industry.

Read this 5-page Top 5 API Testing Myths paper to see the top 5 API testing myths exposed—and learn what's needed to protect your brand in the API Economy.

 

Stay up to date