REST API Data Graph Traversal via Discovery Document and Closure Wrapping

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Developers face challenges in efficiently traversing large data graphs provided by REST APIs, as they often require multiple tedious server calls to retrieve interconnected data object nodes, making it time-consuming to obtain a complete graph.

Innovation Solution

A method involving a discovery document and closure-based queries that allow for efficient traversal of data graphs by wrapping requested data objects with functions for connected nodes, enabling a single server call to retrieve multiple connected objects and collapsing chained closures into a structured markup language object for aggregated results.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Productivity

If developers use traditional REST API calls to retrieve data objects, then they can obtain individual data objects, but they must make repeated server calls to traverse the entire data graph, which is time-consuming and tedious

Engineering Contradiction:
Improvedata retrieval efficiencyVSAvoidtime for multiple server calls
Core Design Contradiction:
ProductivityVSLoss of time

Solution Approach 1:

The system performs preliminary actions by pre-computing and storing the data graph structure and relationships on the server side. When a traversal request is made, the server has already prepared the necessary path information, allowing the client to retrieve complete traversal paths in a single call rather than making multiple sequential calls to discover relationships.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The invention segments the data graph traversal task into two parts: (1) the server handles the complex graph analysis and path computation, and (2) the client receives pre-processed traversal instructions. This segmentation allows the time-consuming graph analysis to be performed server-side while the client performs only lightweight retrieval operations.

Inventive Principle:
Principle #1Segmentation

2Loss of information

If developers make repeated server calls to obtain complete data graphs, then they can retrieve all connected nodes, but the process becomes complex and requires managing multiple requests and responses

Engineering Contradiction:
Improvecompleteness of data graph retrievalVSAvoidcomplexity of managing multiple requests
Core Design Contradiction:
Loss of informationVSDevice complexity

Solution Approach 1:

The invention introduces an intermediary component that acts as a graph traversal service between the client and the data storage system. This intermediary receives a single traversal request, internally manages the complex graph exploration, and returns a complete set of connected nodes and relationships in one response, shielding the client from the complexity of multiple individual requests.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The system merges multiple individual data object retrievals into a single aggregated response. Instead of requiring separate calls for each node and relationship, the invention combines all necessary data objects and their relationships into one comprehensive response that contains the complete traversed graph portion.

Inventive Principle:
Principle #5Merging (Combining)

3Quantity of substance

If the data graph is very large and interconnected, then it contains comprehensive data relationships, but it is infeasible to obtain the entire graph in a single server call using traditional REST APIs

Engineering Contradiction:
Improvesize of data graphVSAvoidfeasibility of retrieving complete graph
Core Design Contradiction:
Quantity of substanceVSEase of operation

Solution Approach 1:

The invention applies partial action by allowing clients to specify traversal parameters such as maximum depth, node types to include, or relationship filters. This enables retrieval of a manageable subset of the large data graph that is sufficient for the client's needs, rather than requiring the entire graph to be fetched at once.

Inventive Principle:
Principle #16Partial or excessive action

Solution Approach 2:

The system implements dynamic traversal where the graph exploration adapts based on client-specified criteria and server-determined optimizations. The traversal can dynamically adjust depth limits, skip certain relationship types, or prioritize certain paths based on the client's needs and the server's understanding of the data structure.

Inventive Principle:
Principle #15Dynamics

Data Source

PatentUS9184980B1Process for traversing through large rest data graph
Publication Date: 2015.11.10 GOOGLE LLC
  • US9184980B1 patent drawing
  • US9184980B1 patent drawing
  • US9184980B1 patent drawing

AI summary

A method for data discovery and retrieval is provided. A REST API client library provides a discovery document for a data graph. The discovery document is structured data containing: (1) a list of data graph endpoints and (2) the format of the information each endpoint returns. The client library uses the REST API to query the server for a data object, wrapping the data object in a new data object. The new data object contains: (1) fixed data from the server-returned data object and (2) a function for each graph node that is directly connected to the requested data object. When these functions execute, the next data objects in the data graph can be retrieved, allowing for quick graph navigation. Given a discovery document and the ability to generate closures based on the document, a query object can be constructed that traverses several layers of the API at once.