API Service Dynamic Schema Configuration for Geographical Variability

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing APIs face challenges in supporting variability across different operational dimensions, such as geographical regions and jurisdictions, requiring frequent changes to source code, which is time-intensive and increases maintenance work, as they need to handle distinct operational requirements like taxation rules and data formats.

Innovation Solution

An API service and variability configuration repository system that determines context data from user requests, matches it to specific entity schemas, and inserts a user-specific metamodel to extend the schema with rules and constraints, allowing for dynamic handling of variability dimensions without hard-coding logic in the main code base.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If operational requirements are hard-coded in application source code to support variability dimensions, then the application can handle different geographical regions and jurisdictions, but the source code requires frequent changes, recompilation, and distribution of update packages

Engineering Contradiction:
Improveability to support different operational requirementsVSAvoidtime for debugging, recompiling, and distributing updates
Core Design Contradiction:
Adaptability or versatilityVSLoss of time

Solution Approach 1:

The patent extracts variability dimensions (geographical region, jurisdiction, industry, business type, business size) from hard-coded source code and places them into a separate configuration repository. This allows operational requirements to be stored externally as configurable parameters rather than being embedded in the application code, enabling changes without recompilation.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The system changes the state of operational requirements from fixed code parameters to dynamic configuration parameters. By storing variability dimensions and their corresponding rules in a configuration repository, the system can modify operational behavior by changing parameter values rather than modifying source code, thus avoiding recompilation and redistribution.

Inventive Principle:
Principle #35Parameter changes

2Adaptability or versatility

If new workflow variations are supported by generating new application source code, then the application can accommodate new jurisdictions and operational requirements, but the code base size increases and maintenance work increases

Engineering Contradiction:
Improveability to support new workflow variationsVSAvoidamount of code to maintain
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent creates a universal configuration repository that serves multiple functions: storing variability dimensions, defining entity schemas, specifying validation rules, and managing workflow variations. This single multi-functional system replaces the need for separate code bases for different jurisdictions and requirements, reducing overall system complexity while maintaining broad adaptability.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Solution Approach 2:

The system transitions from static hard-coded workflows to dynamic configurable workflows. By storing workflow variations and operational requirements in a configuration repository that can be modified at runtime, the system adapts to new jurisdictions and requirements without generating new source code, thus preventing code base bloat and reducing maintenance burden.

Inventive Principle:
Principle #15Dynamics

Data Source

PatentEP3532922B1Processing application programming interface (API) queries based on variable schemas
Publication Date: 2024.04.24 INTUIT INC
  • EP3532922B1 patent drawingFigure 1
  • EP3532922B1 patent drawingFigure 2
  • EP3532922B1 patent drawingFigure 3

AI summary

The present disclosure relates to accessing data using application programming interface (API) calls. According to one embodiment, a method generally includes receiving, at the API, a request from a client device, where the requesting a data operation. Determining context data associated with the request. Receiving an entity schema based on the context data, where the entity schema includes a metamodel. Processing the request using the entity schema and metamodel, generating a response including the entity schema, and returning the response to the client device.