Synchronous API Extension Framework for Microservices

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

In multitenant architectures, extending application programming interfaces (APIs) to meet specific customer needs often leads to increased management and maintenance costs due to the development of wrapper applications and asynchronous event management, which can be complex and resource-intensive.

Innovation Solution

The solution involves defining API extensions at arbitrary locations corresponding to a uniform resource identifier (URI) with trigger conditions, allowing for synchronous processing of intermediate objects, which can be hosted remotely, reducing the need for wrapper application management and asynchronous event handling.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If wrapper applications and asynchronous event management are used to extend APIs, then API extensibility is achieved, but management and maintenance costs increase

Engineering Contradiction:
ImproveAPI extensibilityVSAvoidmanagement and maintenance complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent extracts the extension logic from wrapper applications and asynchronous event management into a dedicated extension framework that processes synchronous requests. This separates the core API functionality from extension logic, allowing extensions to be managed independently without increasing overall system complexity.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The patent introduces an intermediary extension framework that sits between the client and the API service. This framework handles extension processing synchronously, eliminating the need for complex wrapper applications and asynchronous event management while maintaining API extensibility.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Adaptability or versatility

If wrapper applications are developed to extend API functionality, then custom functionality is achieved, but resource consumption increases

Engineering Contradiction:
Improvecustom functionalityVSAvoidresource consumption
Core Design Contradiction:
Adaptability or versatilityVSUse of energy by moving object

Solution Approach 1:

The patent creates a universal extension framework that can handle multiple types of custom functionality through a single synchronous processing mechanism. Instead of developing separate wrapper applications for each custom function, the framework provides a multi-functional platform that reduces overall resource consumption.

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

3Adaptability or versatility

If asynchronous event management is used for API extensions, then flexibility is achieved, but processing time increases

Engineering Contradiction:
Improveprocessing flexibilityVSAvoidprocessing time
Core Design Contradiction:
Adaptability or versatilityVSLoss of time

Solution Approach 1:

The patent inverts the traditional asynchronous event-driven approach by implementing synchronous extension processing. Instead of publishing events and waiting for asynchronous handlers, the system processes extensions synchronously within the request-response cycle, reducing processing time while maintaining flexibility through the extensible framework.

Inventive Principle:
Principle #13The other way round (Inversion)

Data Source

PatentUS10747600B2Extensibility for third party application programming interfaces
Publication Date: 2020.08.18 COMMERCETOOLS GMBH
  • US10747600B2 patent drawing
  • US10747600B2 patent drawing
  • US10747600B2 patent drawing

AI summary

Techniques are disclosed for extending an API using remote, synchronous, user-defined extensions in a microservices environment. A request can be received to perform at least one action on at least one object type, the at least one action defined by an application programming interface (API). At least one extension associated with the at least one action and at least one object type can be determined. An object of the at least one object type and the at least one action can be performed on the object to generate an intermediate object. The intermediate object can be sent to the at least one extension for processing, the at least one extension hosted by a remote service. A response from the at least one extension can be received and the intermediate object can be updated based on the response.