Multi-variant HTTP Requests for Unified Resource Identification

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current HTTP request methods are inflexible and require multiple API calls to access resources, leading to complex sub-resource architectures and ambiguous resource identification, especially when trying to access resources by both identifier and name simultaneously.

Innovation Solution

A multi-variant HTTP request approach that uses tag/value pairs and Boolean expressions within the URI to identify resources, allowing a single API call to access resources based on different field names and values, and enabling flexible access to system entities without the need for sub-resources.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Ease of operation

If traditional HTTP request methods are used to access resources by identifier and name, then multiple API calls are required, but this leads to complex sub-resource architectures and ambiguous resource identification

Engineering Contradiction:
ImproveResource access simplicityVSAvoidAPI architecture complexity
Core Design Contradiction:
Ease of operationVSDevice complexity

Solution Approach 1:

The patent combines multiple resource identification methods (identifier-based and name-based access) into a single unified HTTP request interface. The URI structure integrates both resource identifiers and names in one path, allowing clients to access resources using either method without requiring separate API endpoints or multiple sequential calls, thereby simplifying the API architecture while maintaining operational ease

Inventive Principle:
Principle #5Merging (Combining)

Solution Approach 2:

The HTTP request interface is designed to handle multiple resource access patterns universally through a single endpoint. The URI structure can accommodate both identifier-based paths (e.g., /resources/{id}) and name-based paths (e.g., /resources/name/{name}) within the same interface, making the system multi-functional and eliminating the need for separate specialized endpoints for different access methods

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

2Measurement precision

If multiple API calls are used to access resources, then resource identification can be precise, but this increases the number of requests and communication overhead

Engineering Contradiction:
ImproveResource identification accuracyVSAvoidRequest efficiency
Core Design Contradiction:
Measurement precisionVSProductivity

Solution Approach 1:

The patent merges multiple resource identification criteria into a single HTTP request by integrating both resource identifiers and names in the URI path. This allows the system to maintain precise resource identification through structured URI components while reducing the number of requests needed, as all identification parameters are resolved in one call rather than requiring sequential requests

Inventive Principle:
Principle #5Merging (Combining)

3Adaptability or versatility

If a flexible URI structure with tag/value pairs is used, then a single API call can access resources by different fields, but this requires a new request format

Engineering Contradiction:
ImproveResource access flexibilityVSAvoidRequest format complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The URI structure is designed to be universally applicable across different resource access scenarios. By using a consistent path-based format that can accommodate both identifier and name parameters (e.g., /resources/{parameter}/{value}), the system achieves high versatility without introducing complex query parameters or alternative syntax, maintaining request format simplicity while enabling flexible resource access

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

Solution Approach 2:

The patent utilizes parameter changes in the URI structure to achieve flexibility. By allowing the URI to accept different parameter types (identifiers or names) in standardized position slots, the system can adapt to various resource access needs without changing the fundamental request format. This parameter-based approach enables a single API call to handle multiple access scenarios while keeping the syntax simple and consistent

Inventive Principle:
Principle #35Parameter changes

4Ease of operation

If sub-resources are created for different access methods, then resource access can be specific, but this increases documentation and maintenance burdens

Engineering Contradiction:
ImproveResource access specificityVSAvoidDocumentation and maintenance effort
Core Design Contradiction:
Ease of operationVSEase of manufacture

Solution Approach 1:

The patent implements a universal resource access interface that handles both identifier-based and name-based access through a single endpoint and unified URI structure. This eliminates the need to create and maintain separate sub-resources for different access methods, reducing documentation requirements and maintenance effort while preserving specific resource access capabilities through standardized path parameters

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

Data Source

PatentEP3704559B1Identifying an HTTP resource using multi-variant HTTP requests
Publication Date: 2022.05.04 ORACLE INT CORP
  • EP3704559B1 patent drawingFigure 1
  • EP3704559B1 patent drawingFigure 2A~2C
  • EP3704559B1 patent drawingFigure 3

AI summary

Techniques for multi-variant HTTP requests to identify one or more HTTP resources are disclosed. A server receives an HTTP request to carry out an operation, extracts a field name and a field value recited in the HTTP request, and defines a query based on the field name and the field value. The server executes the query to identify any resources with the field value for a field with the field name and identifies a resource in a set of query results corresponding to the query. The server carries out the operation on the identified resource in the set of query results.