Generic Save Data API for Multi-Table View Configuration
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing view building applications require multiple API creations and integrations for each backend table, leading to increased code complexity and time-consuming modifications due to the need for custom API development for each view configuration and data input/output operation.
Innovation Solution
A generic save data API is integrated into any view, allowing input data to be saved across multiple backend tables without the need for multiple API creations, by using a single API call that includes identifiers of tables, parameters, and input data, and utilizing pre-registered resource information to map applications to tables.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If multiple custom APIs are created and integrated for each backend table to save view data, then data can be saved to multiple tables, but code complexity increases and development time is consumed
Solution Approach 1:
The patent implements a universal save data API that can save view data to any number of backend tables simultaneously. Instead of creating separate custom APIs for each table, the system uses a single generic API that accepts configuration parameters to target multiple tables, thereby achieving multi-functionality without proportionally increasing code complexity
Solution Approach 2:
The patent segments the data saving operation by allowing the single save data API to handle multiple tables through configuration. The view details configuration separates the identification of multiple tables from the actual saving operation, enabling the API to iterate through and save to each table independently without requiring multiple API integrations
2Adaptability or versatility
If custom APIs are developed for each view modification, then view functionality can be extended, but development time and user convenience are reduced
Solution Approach 1:
The patent performs preliminary action by pre-defining the save data API with generic parameters that can accommodate any view configuration. The API is prepared in advance with the capability to handle multiple tables and parameters, so when a view is modified, the same API can be reused without requiring time-consuming custom development
Solution Approach 2:
The save data API is designed as a universal function that works across different view configurations and modifications. By making the API multi-functional and view-agnostic, the system eliminates the need for custom API development for each view change, thereby reducing development time while maintaining adaptability
3Adaptability or versatility
If multiple API calls are integrated into the UI for saving view data, then data can be saved to multiple tables, but ease of operation is reduced due to multiple integrations required
Solution Approach 1:
The patent merges multiple data saving operations into a single API call. Instead of integrating multiple separate API calls into the UI for saving to different tables, the system combines them into one unified save data API that handles all tables simultaneously, thereby simplifying the operation while maintaining multi-table capability
Solution Approach 2:
The save data API is designed as a universal function that can save to any number of tables through a single call. This multi-functional design eliminates the need for multiple separate API integrations in the UI, making the operation easier while preserving the ability to save to multiple tables
Data Source
AI summary
A system for storing input data to parameters included in a view using a generic save data API is provided. The system includes at least one processor configured to execute instructions to: make a save data API call for saving the input data to a plurality of tables, wherein an input of the save data API call comprises identifiers of the plurality of tables and the parameters, and the input data; obtain information of a second application from resource information pre-registered in the first application, the resource information mapping applications to tables respectively associated with the applications; send, based on the obtained information of the second application, a request to the second application to store first input data, from among the input data, to at least one table associated with the second application; and store, by the second application, the first input data to the at least one table.