Browse Prior Art Database

System for Early Detection of Breaking Web API Changes

IP.com Disclosure Number: IPCOM000249186D
Publication Date: 2017-Feb-09
Document File: 3 page(s) / 42K

Publishing Venue

The IP.com Prior Art Database

Abstract

Disclosed is a system that allows stakeholders to detect the first instance of a breaking Web Application Programming Interface (API) change. Additionally, if a breaking API change occurs and the particular request and response is fully cached in the system’s data store, then the cached response can be used, delaying the impact to the user while the stakeholders can start working on a fix right away.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 50% of the total text.

1

System for Early Detection of Breaking Web API Changes

Because Cloud technologies are becoming dominant, interactions through Web Application Programming Interfaces (APIs) are the norm between web services. As applications continue to grow and become more complex, the associated APIs change and quickly evolve over time. This causes a problem for API consumers who must then constantly monitor for changes to the Web APIs on which work depends. Detecting these changes after a break can involve sifting through large log files or waiting for customers to report issues.

In an illustration of the problem, User A is a developer that created a service, which calls out to many different Web APIs including one for web-based video streaming. One day, User A is manually testing the application to see if screenshots from the application’s videos are properly loading on one of the pages in the application. User A discovers that the videos no longer appear. Trying to determine the problem, User A sifts through the application logs and discovers that the screenshots have been broken for some time due to an API change that occurred a week ago .

The novel contribution is a system that allows stakeholders to detect the first instance of a breaking web API change , rather than the first instance that is reported as a customer defect or error log message is seen , which can happen long after the initial breakage is observed. Additionally, if a breaking API change occurs and the particular request and response is fully cached in the data store, then the cached response can be used, delaying the impact to the user for longer while the stakeholders can start working on a fix right away.

Following are the steps for implementing the system in a preferred embodiment : 1. The system records outgoing requests from an application and the corresponding response , and then stores the information

in a data store if it is in a Web API format (e.g., JavaScript* Object Notation) 2. The system correlates similar-looking requests through pattern-matching, tokenizes the parts of Web APIs that change in

these correlations, and combine those into a single entry in the data store 3. If the system identifies a breaking Web API change in these anonymized Web APIs , then it sends a notification to all

configured notification recipients. The system detects a breaking Web API change as one in which : A. The Web API has gone missing (e.g., 404 response code) or, B. One or more of the keys in the response is missing (in the case of a JSON response). C. For Extensible Markup Language (XML) documents, one or more missing tags constitutes a breaking change

4. For request/response pairs with very few possible responses or very frequent calls, the system records the entire request and response in the data store

2

5. In the event that the Hypertext Transfer Protocol (HTTP) headers are changing for each request (e.g., for cookies), the system does not cache the full request/response, for security...