Automated API Documentation Collection via Classification Models

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Conventional APIs lack formal definitions, are often human-readable, and are updated frequently, making it difficult for developers to access and interact with them, especially when dealing with multiple APIs of different types and programming languages, leading to heterogeneity and reduced flexibility in implementation.

Innovation Solution

A system that generates classification models to identify and collect API documentation from various content sources, using machine learning to determine similarity between content and model sentences, allowing for automated collection and storage of API and REST API documents.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Loss of time

If developers manually search for API documentation across multiple sources, then they can access API information, but the time spent searching increases significantly

Engineering Contradiction:
Improvetime spent searching for API documentationVSAvoiddevelopment efficiency
Core Design Contradiction:
Loss of timeVSProductivity

Solution Approach 1:

The system pre-generates classification models containing sentences associated with API documentation before developers need to search. These models are prepared in advance and stored, allowing developers to quickly query against them rather than searching through multiple sources in real-time.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The system creates copies of API documentation content in a standardized format within the classification models. Instead of developers accessing original documentation from multiple sources, the system maintains replicated versions that can be quickly searched and retrieved, reducing access time while preserving the information.

Inventive Principle:
Principle #26Copying

2Adaptability or versatility

If APIs are updated frequently to improve functionality, then the system remains adaptable, but the difficulty of accessing and interacting with consistent documentation increases

Engineering Contradiction:
ImproveAPI functionality adaptabilityVSAvoiddocumentation management complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The classification models serve multiple functions: they store API documentation, enable similarity searching, and provide a standardized interface for accessing different types of API information. This universal structure handles various API types and programming languages through a single system.

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

Solution Approach 2:

The system uses similarity thresholds as adjustable parameters to control how strictly documentation matches are identified. By changing this parameter, the system can adapt to different API update frequencies and documentation styles, maintaining effectiveness whether APIs are updated frequently or infrequently.

Inventive Principle:
Principle #35Parameter changes

3Adaptability or versatility

If developers deal with multiple APIs of different types and programming languages, then system versatility increases, but heterogeneity reduces flexibility in implementation

Engineering Contradiction:
Improvemulti-API support capabilityVSAvoidimplementation flexibility
Core Design Contradiction:
Adaptability or versatilityVSEase of operation

Solution Approach 1:

The system stores sentences associated with different API types and programming languages in a uniform structure within the classification models. All documentation is represented as comparable text segments with similar metadata formats, allowing consistent processing regardless of the original API heterogeneity.

Inventive Principle:
Principle #33Homogeneity

Solution Approach 2:

The classification models act as an intermediary layer between diverse APIs and developers. Instead of developers directly interacting with heterogeneous API documentation in various formats, the models translate and standardize the information, providing a unified access point that simplifies implementation.

Inventive Principle:
Principle #24Intermediary (Mediator)

Data Source

PatentUS10635435B2Collection of API documentations
Publication Date: 2020.04.28 FUJITSU LTD
  • US10635435B2 patent drawing
  • US10635435B2 patent drawing
  • US10635435B2 patent drawing

AI summary

A system may include a memory, a communication interface, and a processor operatively coupled to the communication interface. The processor may be configured to generate a set of classification models. The classification models may include one or more sentences associated with application program interface (API) documentations. The processor may also be configured to access one or more content sources for content. Additionally, the processor may be configured to determine whether one or more sentences in the content is the same or substantially similar to one or more sentences included in the classification models. In response to determining one or more sentences in the content is the same or substantially similar, the processor may be configured to collect the content as API documentation. Additionally, the processor may be configured to categorize different type of API documentations, such as REST API documentations, JAVA API documentations, etc.