Generic API View Data Fetching Reduces Code Complexity

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Existing view building applications require custom API development for each view modification, leading to increased code complexity and user inconvenience due to the need for multiple API creations and integrations.

Innovation Solution

A generic Get API is integrated to fetch resource data for any view, eliminating the need for custom APIs by using a single API across multiple views and configurations, which retrieves view details and combines resource data from various tables.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If custom APIs are developed for each view modification, then data fetching functionality is achieved, but code complexity increases and development time is extended

Engineering Contradiction:

Improveview customization capabilityVSAvoidcode complexity

Core Design Contradiction:

Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent implements a universal API framework that can handle multiple view types and data sources through a single standardized interface. The ViewBuilder component provides generic methods (loadView, saveView, deleteView, etc.) that work across different view configurations without requiring custom API development for each view type. This eliminates the need to create separate APIs for each view modification while maintaining full functionality.

Inventive Principle:

Principle #6Universality (Multi-functionality)

Solution Approach 2:

The system segments the view management functionality into distinct, independent components: ViewBuilder for API operations, ViewConfig for configuration management, and ViewData for data handling. This modular architecture allows each component to handle specific tasks through standardized interfaces, reducing overall system complexity while maintaining adaptability for different view types.

Inventive Principle:

Principle #1Segmentation

2Adaptability or versatility

If custom APIs are developed for each view modification, then specific view data fetching is enabled, but development time increases

Engineering Contradiction:

Improveview configuration flexibilityVSAvoiddevelopment time

Core Design Contradiction:

Adaptability or versatilityVSLoss of time

Solution Approach 1:

The patent implements preliminary action by pre-configuring the ViewBuilder with all necessary API methods and the ViewConfig with default settings before actual view operations. The system establishes a complete framework in advance that can accommodate any view type, eliminating the need for time-consuming custom API development when new views are created. The generic methods are ready to use immediately with any view configuration.

Inventive Principle:

Principle #10Preliminary action

3Reliability

If multiple custom APIs are created for different views, then specific data fetching requirements are met, but integration complexity increases

Engineering Contradiction:

Improvedata fetching accuracyVSAvoidAPI integration complexity

Core Design Contradiction:

ReliabilityVSDevice complexity

Solution Approach 1:

The ViewBuilder provides a universal data fetching mechanism that works across all view types through standardized methods like loadView and loadData. These generic methods handle different data sources and view configurations uniformly, ensuring reliable data fetching without the integration complexity of multiple custom APIs. The system maintains data fetching accuracy through consistent error handling and validation across all operations.

Inventive Principle:

Principle #6Universality (Multi-functionality)

4Adaptability or versatility

If custom APIs are developed for each view, then view-specific functionality is achieved, but user convenience decreases

Engineering Contradiction:

Improveview functionalityVSAvoiduser convenience

Core Design Contradiction:

Adaptability or versatilityVSEase of operation

Solution Approach 1:

The patent implements self-service by enabling the ViewBuilder to automatically handle view configuration and data fetching operations without requiring manual API customization. When a user creates or modifies a view, the system automatically configures the appropriate settings through ViewConfig and executes data operations through generic methods. This eliminates the need for users to understand or manage complex API integrations, significantly improving ease of operation while maintaining full view functionality.

Inventive Principle:

Principle #25Self-service

Data Source

PatentUS12190180B2System and method for obtaining resource data using generic API

Publication Date: 2025.01.07 RAKUTEN SYMPHONY INC

AI summary

A system for fetching resource data of parameters included in a view using a generic get data application programming interface (API) is provided. The system includes at least one processor configured to execute instructions to: make, from a first application, a get data API call for fetching the resource data, wherein an input of the get data API call includes a view identifier; obtain, in response to the API call, view details for the view, wherein the view details include identifiers of the parameters included in the view and identifiers of one or more tables in which the parameters are respectively included; send a request to a second application for resource data of at least one parameter, among the parameters, stored in at least one table associated with the second application, from among the one or more tables; and receive and display, on the view, the requested resource data.