Polymorphic REST Server Framework for Heterogeneous Repositories

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing REST services for heterogeneous content repositories require a complex architecture with multiple REST servers and an API gateway, leading to high implementation and maintenance costs, as well as inefficient resource usage.

Innovation Solution

A polymorphic REST server framework that allows for intelligent decision-making on resource customization at runtime, enabling a single REST server instance to access both provisioned and non-provisioned repositories without the need for an API gateway.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If a complex architecture with multiple REST servers and an API gateway is used to access heterogeneous content repositories, then the system can provide access to multiple repositories, but the implementation and maintenance costs increase and resource usage becomes inefficient

Engineering Contradiction:
Improveaccess to heterogeneous repositoriesVSAvoidarchitecture complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent merges multiple REST servers and an API gateway into a single polymorphic REST server that can handle multiple repository types. The server uses a unified architecture with polymorphic resource representations to access heterogeneous repositories, eliminating the need for separate server instances and gateway components while maintaining the ability to access diverse repository types.

Inventive Principle:
Principle #5Merging (Combining)

Solution Approach 2:

The polymorphic REST server implements multi-functionality by using a single server instance that can adapt to access multiple heterogeneous repository types. The server uses polymorphic resource representations and runtime type determination to provide universal access to different repository formats, replacing the need for specialized servers for each repository type.

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

2Adaptability or versatility

If multiple REST servers are deployed to access different content repositories, then repository access capability is enhanced, but implementation and maintenance costs increase

Engineering Contradiction:
Improverepository access capabilityVSAvoidimplementation and maintenance cost
Core Design Contradiction:
Adaptability or versatilityVSEase of manufacture

Solution Approach 1:

The patent implements a single polymorphic REST server that provides universal access to multiple heterogeneous repositories. The server determines the repository type at runtime based on resource representation analysis, eliminating the need to deploy and maintain multiple specialized servers. This reduces implementation costs, simplifies maintenance, and lowers infrastructure requirements while maintaining full repository access capability.

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

3Ease of operation

If an API gateway is introduced to manage access to heterogeneous repositories, then centralized control is achieved, but the system architecture becomes more complex and resource usage less efficient

Engineering Contradiction:
Improvecentralized controlVSAvoidsystem architecture
Core Design Contradiction:
Ease of operationVSDevice complexity

Solution Approach 1:

The patent extracts the gateway functionality from a separate component and integrates it directly into the polymorphic REST server. The server internally determines repository types and routes requests appropriately based on resource representation analysis, eliminating the need for a separate API gateway layer. This maintains centralized control while simplifying the overall system architecture and improving resource efficiency.

Inventive Principle:
Principle #2Taking out (Extraction)

4Adaptability or versatility

If multiple REST server instances are used to access heterogeneous repositories, then repository-specific access requirements are met, but resource usage efficiency decreases

Engineering Contradiction:
Improverepository-specific accessVSAvoidresource usage efficiency
Core Design Contradiction:
Adaptability or versatilityVSProductivity

Solution Approach 1:

The patent implements a dynamic polymorphic REST server that adapts its behavior at runtime based on the repository type being accessed. The server determines the appropriate resource representation format dynamically based on the target repository, allowing a single server instance to efficiently access multiple heterogeneous repositories without requiring static configuration or multiple dedicated server instances, thereby optimizing resource usage.

Inventive Principle:
Principle #15Dynamics

Data Source

PatentUS12289370B2Systems and methods for building and providing polymorphic rest services for heterogeneous repositories
Publication Date: 2025.04.29 OPEN TEXT CORP
  • US12289370B2 patent drawing
  • US12289370B2 patent drawing
  • US12289370B2 patent drawing

AI summary

Responsive to a request to access heterogeneous repositories, a REST server queries a resource registry to find resources that match mapping information contained in the request. The resource registry returns resource registry tables containing the matching resources. The resource registry tables implement a unified data structure of a resource registry model and are generated at runtime by the resource registry mapping REST service configuration parameters to the fields of the unified data structure. The REST service configuration parameters are added to an extension SDK for REST extension developers to enhance REST service configuration for extension applications. The REST service configuration parameters are configured at implementation time and loaded/scanned into the REST server at runtime. The REST server iteratively evaluates the resource registry tables until all the matching resources have been evaluated. The evaluation result is used to determine whether to reject, accept, or redirect the request from the client device.