Static API Specification Inference for REST Applications

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current methods for creating comprehensive specifications for REST APIs are largely manual and tedious, especially for large and complex applications, and rely on dynamic solutions that are under-approximate and non-exhaustive.

Innovation Solution

A method and system that identify entry points in a web application using static analysis to infer parameter types, generating a statically generated API specification that includes type propagation, and merging it with dynamically generated specifications to create a more comprehensive and accurate API specification.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Measurement precision

If manual methods are used to create comprehensive specifications for REST APIs, then the specifications can be detailed and accurate, but the process becomes tedious and time-consuming, especially for large and complex applications

Engineering Contradiction:
Improvespecification accuracyVSAvoidspecification creation time
Core Design Contradiction:
Measurement precisionVSLoss of time

Solution Approach 1:

The patent performs static analysis on the application code before runtime to pre-identify entry points, parameters, and their types. This preliminary action creates a foundation that reduces the need for manual specification creation and accelerates the overall process while maintaining accuracy.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent introduces a hybrid approach that acts as an intermediary between manual specification creation and purely dynamic approaches. The static analysis component serves as a mediator that automatically generates initial specifications, which can then be refined manually or enhanced through dynamic testing, reducing both time and effort.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Extent of automation

If purely dynamic solutions are used to extract API specifications, then the process is automated, but the solutions are under-approximate and non-exhaustive by nature

Engineering Contradiction:
Improvespecification extraction automationVSAvoidspecification completeness
Core Design Contradiction:
Extent of automationVSReliability

Solution Approach 1:

The patent segments the specification extraction process into two distinct phases: static analysis (compile-time/code inspection) and dynamic analysis (runtime observation). Each phase complements the other, with static analysis providing comprehensive coverage of all possible entry points and parameters, while dynamic analysis validates actual usage patterns.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent merges static analysis results with dynamic analysis results to create a comprehensive API specification. The static analysis provides the complete set of possible parameters and entry points, while dynamic analysis confirms actual usage, together eliminating the under-approximation problem of purely dynamic solutions.

Inventive Principle:
Principle #5Merging (Combining)

3Extent of automation

If developers use proxy to dynamically capture requests and responses, then API specifications can be generated automatically, but developers must manually exercise all entry points and supply all possible parameters which is nearly impossible for large and complex applications

Engineering Contradiction:
Improvespecification generation automationVSAvoidtesting complexity
Core Design Contradiction:
Extent of automationVSDevice complexity

Solution Approach 1:

The patent performs static analysis to pre-identify all entry points and parameters before runtime testing. This preliminary identification creates a map of the application's API surface, allowing the testing system to automatically generate appropriate test cases without requiring manual exploration of every entry point.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent uses dynamic analysis to observe actual runtime behavior and feed this information back to refine the API specification. The system learns from actual requests and responses, automatically adjusting the specification to match real usage patterns without requiring manual intervention to discover new entry points or parameters.

Inventive Principle:
Principle #23Feedback

Data Source

PatentUS11755744B2Application programming interface specification inference
Publication Date: 2023.09.12 ORACLE INT CORP
  • US11755744B2 patent drawing
  • US11755744B2 patent drawing
  • US11755744B2 patent drawing

AI summary

A method may include identifying, by executing an application, an entry point corresponding to a Universal Resource Locator (URL) path, extracting, from the application, an entry point declaration corresponding to the entry point, determining, by performing a static analysis starting at the entry point declaration, that a parameter is accessible by the application, and inferring, by the static analysis, a type of the parameter by analyzing usage of the parameter by the application.