REST API Translation Proxy for Database Schema Evolution
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing REST APIs face compatibility issues when the underlying database schema model evolves, leading to failed transactions for clients using older API versions, and existing solutions either refrain from updating the model, decouple the API from the schema, or result in data duplication and high memory costs.
Innovation Solution
A translation proxy is introduced between the REST APIs and the OVSDB server, allowing multiple API versions to coexist while maintaining a single schema model, intercepting transactions, and translating between older and newer models, enabling backwards compatibility.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If the database schema model is updated to add new features, then the system functionality is improved, but clients using older API versions experience failed transactions and compatibility issues
Solution Approach 1:
A translation proxy is introduced as an intermediary component between REST API clients and the OVSDB server. The proxy intercepts API calls from clients using older schema versions, translates them into calls compatible with the current schema version, and forwards them to the server. This mediator resolves the compatibility conflict by allowing the database schema to evolve while maintaining support for legacy clients without requiring them to upgrade.
2Reliability
If multiple API versions are supported to maintain backwards compatibility, then client compatibility is improved, but data duplication and memory costs increase
Solution Approach 1:
Instead of maintaining multiple complete copies of the database schema for different API versions, the system creates a lightweight translation layer that copies only the necessary schema mapping information. The translation proxy stores mapping rules that translate old schema references to new schema references, avoiding the need to duplicate actual data while still supporting multiple API versions.
3Adaptability or versatility
If the REST API is decoupled from the database schema model, then API version independence is improved, but the complexity of maintaining and updating the API increases
Solution Approach 1:
The system segments the API architecture into distinct layers: the translation proxy layer that handles version compatibility, the core REST API layer that remains relatively stable, and the database schema layer that evolves independently. This segmentation allows each layer to be maintained and updated separately, reducing the overall complexity by isolating the translation logic from the core API implementation.
Data Source
AI summary
During operation, the system receives a request, via a REST API, for data stored in a database which uses a schema associated with a current version, wherein the request indicates a version of the REST API. Responsive to determining that the indicated version is a prior version of the REST API which does not correspond to the current version of the database schema, the system: dispatches the request to a translation proxy; applies rules which converts the request to indicate an updated REST API version corresponding to the current version of the schema; obtains results from the database based on the converted request and the applied rules; and returns the results, wherein the prior version of the REST API comprises an old version and wherein the current version of the schema comprises a new version, which enables functionality from the new version to work with the old version.