Three ways that APIs can fail

Software changes break existing code

When development teams don’t take care to fully support the backward compatibility of APIs, an API that previously worked may not work as it should in an updated or completely new version. 

With each new version, additional parameters may be required, results may be delivered in different formats, and even when developers maintain backward compatibility, old APIs may continue to work, but only for a limited time.

Teams consuming APIs may be unaware of the new changes to the APIs until a sudden failure occurs. If this happens, teams must track the failure to its source to find the root cause of the problem and verify that documentation is up to date – a time-consuming and costly process.

The same applies for dependency changes as APIs rely on other services and applications that are subject to updates. By tracking dependencies and support application changes and making updates when needed, teams can avoid unexpected API failures.  

Communication breakdown

Communication is a foundational element of APIs – and if it breaks down, there can be a ripple effect of unintended consequences. Often, the application or service that teams want to connect with is online, generally as a software-as-a-service (SaaS) cloud-based offering versus on-premise via a desktop. But if the connection doesn’t work, a seamless redirection to an alternative address isn’t guaranteed, and you may encounter error codes or no response at all.

Anticipating and planning for these types of event is imperative to maintain strong customer experiences. One possible outcome could be that data attempting to be transmitted gets stored in a temporary cache and continues trying to transmit offline until it is successful.

No matter what the correct course of action is during a failure, anticipating and planning for the failure is always the better approach. Monitoring APIs ensures teams discover failures as quickly as possible, enabling quicker resolutions and minimised customer impact.

Incompatible data

APIs move and pass data in many directions, making it difficult for teams to identify its origin or what has happened to the data throughout its journey – potentially experiencing formatting issues. Incompatible data generally occurs between two services and not an API directly interacting with the consumer. To catch and rectify incompatible data, it is important to test provider/consumer contracts for each and every API/service. This is known as contract testing.

Testing and monitoring your API’s quality and performance cannot be sidelined in today’s modern business world, which so heavily relies on the back-end performance of these applications. Although software changes, communication breakdowns and incompatible data are not an exhaustive list of why APIs fail, these top reasons are experienced far too often.

Microservices exacerbate the problem because each service is developed and deployed independently of each and every other service. This creates a higher chance of a change or data incompatibility that will break an entire business process. 

IT teams must improve their API monitoring and testing across the entire development lifecycle to increase resiliency, find bugs more quickly and fix issues earlier. Anticipating and preparing for failures can help prevent them and track performance more holistically.

While we are not at a point in technology’s history where we can fully prevent all API failures, the tech team responsible for developing and maintaining these APIs can contain potential damage and avert failure by making a concerted effort around these applications

Stephen Feloney is a vice-president at Perforce responsible for continuous testing products.