Proxy Container for Synchronous API Execution
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Synchronous APIs often block callers due to system slowdowns and uncontrolled third-party APIs, leading to performance issues and difficulties in handling long-running tasks without adequate timeout parameters.
Innovation Solution
Executing synchronous APIs within a proxy container, allowing the caller to proceed with other processing while the proxy waits for the API result, with monitoring and timeout mechanisms to manage the proxy's execution.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Ease of operation
If synchronous APIs are used to ensure simple communication and integration between applications, then ease of operation is improved, but productivity deteriorates due to blocking behavior that prevents the caller from proceeding with other processing
Solution Approach 1:
The patent segments the synchronous API execution from the caller application by introducing a proxy application. The caller application makes the synchronous API call to the proxy, which then executes the API call separately. This segmentation allows the caller to continue processing without being blocked, while the proxy handles the blocking operation independently.
Solution Approach 2:
The proxy application serves as an intermediary between the caller application and the target application. It receives synchronous API calls from the caller, executes them, and returns results without blocking the caller. This intermediary pattern resolves the contradiction by mediating the blocking behavior away from the caller while maintaining the simplicity of synchronous API usage.
2Ease of operation
If synchronous APIs are used to maintain simple programming models, then ease of operation is improved, but loss of time increases due to indefinite waiting for third-party API results
Solution Approach 1:
The proxy application is pre-configured with timeout parameters and monitoring mechanisms before executing synchronous API calls. This preliminary setup allows the system to automatically terminate waiting after a specified duration, preventing indefinite time loss while maintaining the simple synchronous API interface for callers.
Solution Approach 2:
The proxy application implements feedback mechanisms through monitoring and timeout parameters that provide control over the execution of synchronous API calls. The system can monitor the proxy's execution and terminate it based on predefined time limits, creating a feedback loop that prevents excessive waiting time while preserving the ease of synchronous API usage.
3Ease of operation
If synchronous APIs are used to ensure straightforward error handling, then ease of operation is improved, but reliability deteriorates when third-party APIs block callers due to system slowdowns or unexpected data sizes
Solution Approach 1:
The proxy application acts as a protective intermediary that isolates the caller application from reliability issues in third-party APIs. The proxy handles blocking, timeouts, and errors independently, preventing these issues from propagating to the caller and compromising system reliability, while the caller continues to use simple synchronous API calls.
Solution Approach 2:
The system implements beforehand cushioning by configuring timeout parameters and monitoring mechanisms in advance within the proxy application. These pre-established safeguards cushion against potential reliability issues such as system slowdowns or unexpected data sizes from third-party APIs, preventing them from causing indefinite blocking or failures in the caller application.
Data Source
AI summary
Techniques are described for utilizing synchronous APIs which normally block callers until a result is returned. In particular, the techniques described herein enable an application or other programming construct to boost performance by executing synchronous APIs (e.g., long running time APIs) within a proxy container rather than executing the synchronous APIs in the context of the application itself. Since the proxy is a separate process or thread, the caller application is thereby released from waiting for the synchronous API call and may proceed with other processing instead of waiting for the synchronous API to return. The application may then monitor the proxy to determine whether a result has been received, such as by periodically polling the proxy.


