Generic API System Dynamic Metadata Access
Solution Overview
Problem
Existing APIs require specific coding for each business function and are tied to fixed data locations, making it difficult to access data from multiple data centers with different programming languages, as they need to define native access paths, which can be cumbersome and limit flexibility.
Innovation Solution
A generic API system is introduced that operationally separates the user interface, data access layer, and data storage layer, utilizing metadata logic like XML to dynamically define data locations, allowing data retrieval from various data centers with different programming languages without requiring specific coding for each business function or fixed data locations.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If a traditional API is coded specifically for each business function with fixed data locations, then data retrieval is straightforward for that specific function, but the API lacks flexibility and requires separate development for each business function
Solution Approach 1:
The patent implements a universal API framework that can handle multiple business functions through a single unified interface. The system uses a metadata-driven approach where business logic is separated from the API layer, allowing the same API infrastructure to serve different business functions by changing the metadata configurations rather than writing new code for each function.
Solution Approach 2:
The patent introduces dynamic access paths that can be configured at runtime based on business requirements. Instead of hardcoding fixed data locations in the API, the system uses configurable metadata that allows access paths to be dynamically adjusted. This enables the API to adapt to different business functions without requiring separate API developments, resolving the contradiction between flexibility and complexity.
2Adaptability or versatility
If an API uses fixed access paths to data locations, then data retrieval is efficient for known locations, but the API cannot easily access data from multiple data centers with different programming languages
Solution Approach 1:
The patent introduces a metadata layer as an intermediary between the API and the underlying data centers. This metadata layer abstracts the complexity of different data center programming languages and access paths. The API interacts with a unified metadata interface, which then translates requests into the appropriate language-specific queries for each data center, maintaining ease of operation while enabling multi-data center access.
Solution Approach 2:
The patent segments the data access architecture into distinct layers: the API layer, the metadata layer, and the data center layer. Each layer has a specific responsibility, with the metadata layer handling the complexity of different data center protocols and languages. This segmentation allows the API to remain simple and language-agnostic while still accessing multiple data centers with different programming languages through the intermediary metadata layer.
3Measurement precision
If developers must be familiar with fixed access paths and programming languages of each data center, then precise data retrieval is achieved, but the learning curve and operational difficulty increase
Solution Approach 1:
The patent implements a self-service metadata system that automatically manages data center access paths and programming language translations. Instead of requiring developers to manually learn and configure access paths for each data center, the system provides automated metadata generation and management capabilities. The metadata layer automatically handles the translation between unified API calls and data center-specific queries, eliminating the need for developers to have deep familiarity with each data center's programming language while maintaining precise data retrieval.
Data Source
AI summary
A system may include a user interface, a processor, and a memory having a program communicatively connected to the user interface. The program may include a data access layer and a data storage layer. The processor being configured to retrieve a data request having a record type and a data type from the user interface, retrieve an execution plan from the data access layer based on the record type, retrieve a map from the data access layer based on the data type, retrieve data from the data storage layer based on the execution plan and the map, and provide data to the user interface.