Adaptable API Server Evolution Without Client Breakage

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Evolving a server to change non-trivial aspects of its implementation without breaking pre-existing client assumptions is challenging, leading to issues like expensive deployments or broken clients when upgrading APIs in client-server configurations.

Innovation Solution

Defining an adaptable API that allows clients and servers to evolve independently while maintaining interoperability by mapping an application domain object model onto an XHTML-based RESTful API, providing degrees of freedom in URL space, data representation, and form structure, enabling servers to modify functionality without breaking clients.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If a server is evolved to change non-trivial aspects of its implementation, then the server's functionality and adaptability are improved, but pre-existing clients break and interoperability is lost

Engineering Contradiction:

Improveserver evolution capabilityVSAvoidclient-server interoperability

Core Design Contradiction:

Adaptability or versatilityVSReliability

Solution Approach 1:

The patent implements dynamic adaptability where the server can evolve its implementation while maintaining interoperability through runtime adaptation mechanisms. The system dynamically adjusts to changes in server implementation without requiring client updates, allowing the server to modify its behavior and structure while preserving the contract with pre-existing clients.

Inventive Principle:

Principle #15Dynamics

Solution Approach 2:

The patent utilizes parameter changes to enable server evolution. By allowing the server to modify implementation parameters while maintaining the same interface contract, the system achieves non-trivial server updates without breaking clients. This includes changing internal representations, data structures, and processing logic while preserving the external API contract.

Inventive Principle:

Principle #35Parameter changes

2Reliability

If multiple API versions are maintained to support server evolution, then client compatibility is preserved, but system complexity and deployment cost increase

Engineering Contradiction:

Improveclient compatibilityVSAvoidAPI version management

Core Design Contradiction:

ReliabilityVSDevice complexity

Solution Approach 1:

The patent implements a universal adaptation mechanism that handles multiple server implementations through a single unified interface. The hypermedia API serves multiple functions: it acts as both the client interface and the adaptation layer, eliminating the need for separate version management while maintaining compatibility across different server implementations.

Inventive Principle:

Principle #6Universality (Multi-functionality)

Solution Approach 2:

The patent introduces a hypermedia API as an intermediary layer between clients and the server implementation. This mediator handles the complexity of server evolution by absorbing changes internally while presenting a stable interface to clients, thus eliminating the need for multiple API versions and reducing deployment complexity.

Inventive Principle:

Principle #24Intermediary (Mediator)

3Reliability

If coordinated client upgrades are required for server updates, then interoperability is maintained, but deployment time and coordination overhead increase

Engineering Contradiction:

ImproveinteroperabilityVSAvoiddeployment time

Core Design Contradiction:

ReliabilityVSLoss of time

Solution Approach 1:

The patent implements self-service adaptation where the hypermedia API automatically adjusts to server changes without requiring coordinated client upgrades. The system performs self-adaptation by interpreting server responses and adjusting its behavior accordingly, eliminating the need for manual coordination and reducing deployment time to near zero.

Inventive Principle:

Principle #25Self-service

Solution Approach 2:

The patent prepares the system for future server changes by implementing a hypermedia API that is designed to be inherently adaptable. This preliminary design decision enables the system to handle server evolution without requiring subsequent coordination, as the adaptation capability is built-in from the outset rather than added later.

Inventive Principle:

Principle #10Preliminary action

4Adaptability or versatility

If clients are made upgradeable on demand, then server evolution is supported, but clients deployed in unmanaged environments cannot be upgraded

Engineering Contradiction:

Improveserver evolution supportVSAvoidclient upgradeability

Core Design Contradiction:

Adaptability or versatilityVSEase of operation

Solution Approach 1:

The patent inverts the traditional upgrade model by making the server adaptable to clients rather than requiring clients to upgrade to match the server. The hypermedia API on the client side interprets server responses and adapts its behavior, allowing servers to evolve while clients remain unchanged. This approach works in unmanaged environments where clients cannot be upgraded.

Inventive Principle:

Principle #13The other way round (Inversion)

Data Source

PatentUS9160789B2Adaptable application programming interfaces and specification of same

Publication Date: 2015.10.13 COMCAST CABLE COMM LLC

AI summary

Aspects of the disclosure relate to defining and/or specifying an application programming interface (API) between a client and a computing device (such as a server) in a manner that the client, the computing device, or both, can evolve independently while preserving inter-operability.