REST API Change Notification via Publish-Subscribe Server

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

In cloud computing environments, developers face challenges in responding quickly to unanticipated changes in Representational State Transfer (REST) Application Programming Interfaces (APIs), which can lead to web application failures during automated software testing due to the constant evolution of these APIs without notice.

Innovation Solution

A publish/subscribe architecture is implemented that allows subscribers to customize their requests for REST API change notifications, enabling automatic detection and reporting of changes, thereby facilitating quicker responses to API updates and improving testing efficiency.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If REST APIs are constantly updated during development and maintenance cycles, then the functionality and adaptability of the system improve, but the reliability of web applications deteriorates due to unanticipated changes causing application failures

Engineering Contradiction:

ImproveAPI functionalityVSAvoidapplication stability

Core Design Contradiction:

Adaptability or versatilityVSReliability

Solution Approach 1:

The system performs preliminary actions by proactively detecting REST API changes before they cause application failures. The change detection mechanism monitors API specifications and compares them against stored baselines, enabling the system to prepare for upcoming changes and notify developers in advance, thus preventing reliability issues before they occur.

Inventive Principle:

Principle #10Preliminary action

Solution Approach 2:

The system implements feedback by continuously monitoring REST API changes and providing notifications to developers. The notification mechanism delivers change information back to the development team, enabling them to adjust their applications proactively. This closed-loop feedback system maintains reliability while allowing API adaptability to improve.

Inventive Principle:

Principle #23Feedback

2Reliability

If developers manually monitor REST API changes, then they can respond to updates, but the time required to detect and respond to changes increases significantly

Engineering Contradiction:

Improvechange detection capabilityVSAvoidresponse time

Core Design Contradiction:

ReliabilityVSLoss of time

Solution Approach 1:

The system performs self-service by automatically detecting REST API changes without requiring manual developer intervention. The change detection mechanism autonomously monitors API specifications, compares them against stored baselines, and generates notifications. This automation eliminates the time-consuming manual monitoring process while maintaining reliable change detection capability.

Inventive Principle:

Principle #25Self-service

Solution Approach 2:

The system replaces the mechanical manual monitoring process with an automated electronic detection mechanism. Instead of developers manually checking API changes, the system uses automated tools to detect, compare, and notify about changes. This substitution dramatically reduces response time while maintaining detection reliability.

Inventive Principle:

Principle #28Mechanics substitution (Replace mechanical system)

3Loss of information

If comprehensive monitoring of all REST API changes is implemented, then complete change visibility is achieved, but the complexity of the monitoring system increases

Engineering Contradiction:

Improvechange visibilityVSAvoidmonitoring system complexity

Core Design Contradiction:

Loss of informationVSDevice complexity

Solution Approach 1:

The system extracts only the essential change information from comprehensive API monitoring data. Instead of presenting all possible change details, the notification mechanism extracts and delivers only the critical information developers need to respond to changes. This reduction maintains complete change visibility while simplifying the monitoring system's output and reducing its effective complexity.

Inventive Principle:

Principle #2Taking out (Extraction)

Solution Approach 2:

The system segments the monitoring functionality into distinct modular components: API specification retrieval, change detection, comparison logic, and notification delivery. This segmentation allows each component to handle specific aspects of monitoring independently, making the overall system more manageable and less complex while maintaining comprehensive change visibility through the coordinated operation of these modules.

Inventive Principle:

Principle #1Segmentation

Data Source

PatentUS11586697B2Publishing rest API changes based on subscriber's customized request

Publication Date: 2023.02.21 VMWARE INC

AI summary

System and methods for automatically publishing Representational State Transfer (REST) Application Programming Interface (API) changes in a cloud environment are described. A publish/subscribe server (PSS) may receive from a subscriber a customized request for monitoring a registered REST API supported by a REST service provider (RSP) and registered with the PSS. The subscriber is configured to invoke the registered REST API at the RSP. The PSS may monitor the registered REST API for any changes at the RSP based on the customized request. In response to a determination that the registered REST API is changed at the RSP, the PSS may generate a REST API change report indicating a change event occurred to the registered REST API at the RSP after being registered with the PSS. The PSS may then transmit the REST API change report to the subscriber. The subscriber is configured to not invoke the registered REST API at the RSP based on the REST API change report.