Regeneration Audit Log for Federated API Version Control
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
The configuration of applications to access multiple APIs with different authentication settings and response times leads to significant overhead and inefficiencies, resulting in built-in latencies due to dependencies on responses from multiple APIs.
Innovation Solution
Implementing a regeneration audit log system that stores individual modifications to data sources and their schemas, allowing for the efficient generation of previous versions of a federated API by applying changes from the log, and using snapshotting to reduce processing time for large quantities of changes.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If applications access multiple APIs with different authentication settings, then service functionality is improved, but configuration overhead and latency increase
Solution Approach 1:
The patent merges multiple separate API access configurations into a single federated API configuration. Instead of configuring each API individually with its own authentication settings, the system provides a unified configuration interface that consolidates access to multiple data sources, thereby reducing configuration overhead while maintaining the ability to access diverse services
Solution Approach 2:
The federated API acts as an intermediary layer between applications and multiple underlying data sources. This mediator handles the complexity of accessing multiple APIs with different authentication settings, allowing applications to interact with a single standardized interface while the federated API manages the underlying complexity of multiple data source connections
2Adaptability or versatility
If applications ping multiple APIs to perform services, then service completeness is improved, but latency increases due to dependencies on responses from multiple APIs
Solution Approach 1:
The system performs preliminary actions by pre-fetching and caching data from multiple data sources before it is actually needed by the application. The federated API can proactively retrieve data from underlying sources and store it in cache, so when an application requests the data, it is already available or nearly available, significantly reducing the latency associated with waiting for multiple API responses
3Manufacturing precision
If previous versions of federated API are regenerated by reprocessing all changes from the log, then version accuracy is improved, but processing time increases significantly for large quantities of changes
Solution Approach 1:
The system performs preliminary actions by creating and storing snapshots of the federated API at specific points in time. These snapshots capture the state of the API configuration and underlying data sources at particular moments, allowing previous versions to be regenerated by retrieving the appropriate snapshot rather than reprocessing all changes from the beginning, thereby maintaining version accuracy while dramatically reducing processing time
Solution Approach 2:
The change event log is segmented into manageable portions associated with different snapshots. Instead of treating the entire log as a single continuous sequence that must be reprocessed, the system divides the log into segments between snapshots, allowing selective reprocessing of only the necessary portions when regenerating previous API versions
Data Source
AI summary
A federation management service may generate a federated application program interface (API) based on multiple data sources. The federation management service may detect changes to one or more of the multiple data sources, which may result in generation of a new version of the federated API. The changes to the data sources may be documented in a change event log. The change event log may be used to recreate a prior version of the federated API by applying changes of the change event log to a federated schema corresponding to the federated API. A snapshotting technique may capture the state of the federated schema at various points in time, and snapshots may be used to regenerate a prior version of the federated API using the change events of the change event log.