Patent Publication Number: US-10761838-B2

Title: Generating unified and dynamically updatable application programming interface documentation from different sources

Description:
FIELD 
     The field relates generally to information processing systems, and more particularly to the generation and dynamic modification of application programming interface (API) documentation from different source files. 
     BACKGROUND 
     Unifying redundant technologies is important for organizational success, and it has become important to achieve synergy within an organization among the computer technology products which may be coming from different sources. 
     For example, application programming interfaces (APIs) from different products are consumed heavily among customers. However, the structure, look and feel of the APIs across different product lines and their documentation are different for different set of APIs. In terms of usability, the differences between APIs and their documentation adversely affects user experience. 
     In web service hosting APIs should have corresponding electronic documentation describing the APIs in comprehensive enough detail to enable customers and application developers to use the API. In addition, APIs are dynamic in nature. For example, the generation, customization and modification of an API can happen instantly. As APIs evolve and new APIs are released, the documentation needs to be accurate and obviously reflect changes in the APIs. Currently, supporting reference documents require manual updates, causing a variety of associated process and quality complications, and resulting in time consuming processes that are not able to keep pace with the dynamic nature of the APIs. In addition, there is no centralized location for APIs corresponding to different products. 
     Accordingly, there is a need for an improved computer driven structure and process which is capable of dynamically modifying API documentation in response to API evolution, and providing unified API documentation from different source documents. 
     SUMMARY 
     In one embodiment, an apparatus comprises at least one processing platform including a plurality of processing devices. The processing platform is configured to generate a document corpus comprising a plurality of application programming interface electronic documents, wherein the plurality of application programming interface electronic documents are organized according to one or more application programming interface versions, receive a query from one or more users seeking information corresponding to one or more application programming interfaces, generate a subset of the plurality of application programming interface electronic documents in response to the query using one or more code artifacts, retrieve data corresponding to the one or more application programming interface versions, dynamically modify one or more of the plurality of application programming interface electronic documents in the subset of the plurality of application programming interface electronic documents based on the retrieved application programming interface version data, and transmit the subset of the plurality of application programming interface electronic documents to the one or more users. 
     These and other illustrative embodiments include, without limitation, apparatus, systems, methods and computer program products comprising processor-readable storage media. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is a block diagram of an information processing system comprising an application programming interface (API) documentation platform configured for generating and dynamically updating application programming interface (API) documentation from different source files in an illustrative embodiment. 
         FIG. 2  is a block diagram of a document corpus of the application programming interface (API) documentation platform in an illustrative embodiment. 
         FIG. 3  is a block diagram of build and webserver environments of the application programming interface (API) documentation platform in an illustrative embodiment. 
         FIG. 4  is a block diagram of operation of a document formatter of a document generation engine of the application programming interface (API) documentation platform in an illustrative embodiment. 
         FIG. 5  is a flow diagram of a process for generating and dynamically updating application programming interface (API) documentation from different source files in an illustrative embodiment. 
         FIGS. 6 and 7  show examples of processing platforms that may be utilized to implement at least a portion of an information processing system in illustrative embodiments. 
     
    
    
     DETAILED DESCRIPTION 
     Illustrative embodiments will be described herein with reference to exemplary information processing systems and associated computers, servers, storage devices and other processing devices. It is to be appreciated, however, that these and other embodiments are not restricted to the particular illustrative system and device configurations shown. Accordingly, the term “information processing system” as used herein is intended to be broadly construed, so as to encompass, for example, processing systems comprising cloud computing and storage systems, as well as other types of processing systems comprising various combinations of physical and virtual processing resources. An information processing system may therefore comprise, for example, at least one data center or other cloud-based system that includes one or more clouds hosting multiple tenants that share cloud resources. Such systems are considered examples of what are more generally referred to herein as cloud-based computing environments. Some cloud infrastructures are within the exclusive control and management of a given enterprise, and therefore are considered “private clouds.” The term “enterprise” as used herein is intended to be broadly construed, and may comprise, for example, one or more businesses, one or more corporations or any other one or more entities, groups, or organizations. An “entity” as illustratively used herein may be a person or system. On the other hand, cloud infrastructures that are used by multiple enterprises, and not necessarily controlled or managed by any of the multiple enterprises but rather respectively controlled and managed by third-party cloud providers, are typically considered “public clouds.” Examples of public clouds may include, but are not limited to, Amazon Web Services® (AWS), Google Compute Engine® (GCE), and Microsoft Azure® Services platforms. Thus, enterprises can choose to host their applications or services on private clouds, public clouds, and/or a combination of private and public clouds (hybrid clouds) with a vast array of computing resources attached to or otherwise a part of the infrastructure. Numerous other types of enterprise computing and storage systems are also encompassed by the term “information processing system” as that term is broadly used herein. 
     As used herein, “real-time” refers to output within strict time constraints. Real-time output can be understood to be instantaneous or on the order of milliseconds or microseconds. Real-time output can occur when the connections with a network are continuous and a user device receives messages without any significant time delay. Of course, it should be understood that depending on the particular temporal nature of the system in which an embodiment of the invention is implemented, other appropriate timescales that provide at least contemporaneous performance and output can be achieved. 
     As used herein “application programming interface (API)” refers to a set of subroutine definitions, protocols, and/or tools for building software. Generally, an API defines communication between software components. APIs permit programmers to write software applications consistent with an operating environment or website. 
     As used herein “application programming interface (API) documents” and “application programming interface (API) documentation” provide users with descriptions of the services offered by an API, and how to use those services. API documentation provides users with necessary information to develop and maintain applications using an API. Restrictions and/or limitations regarding API use may also be set forth in the documentation. API documentation can be retrieved from a variety of sources, including, but not limited to, databases of documentation files, blogs, forums, and question and answer websites. API documentation may include metadata information like Java annotations, which can be used by software components to implement custom behaviors or custom handling of the API. 
       FIG. 1  shows an information processing system  100  configured in accordance with an illustrative embodiment. The information processing system  100  comprises user devices  102 - 1 ,  102 - 2 , . . .  102 -M (collectively “user devices  102 ). The user devices  102  communicate over a network  104  with an API documentation platform  110 . 
     The user devices  102  can comprise, for example, desktop, laptop or tablet computers, mobile telephones, or other types of processing devices capable of communicating with the API documentation platform  110  over the network  104 . The variable M and other similar index variables herein such as K, L, N and Z are assumed to be arbitrary positive integers greater than or equal to two. 
     The term “user” herein is intended to be broadly construed so as to encompass numerous arrangements of human, hardware, software or firmware entities, as well as combinations of such entities. Document generation services may be provided for users utilizing one or more machine learning models, although it is to be appreciated that other types of infrastructure arrangements could be used. At least a portion of the available services and functionalities provided by the API documentation platform  110  in some embodiments may be provided under Function-as-a-Service (“FaaS”) and/or Platform-as-a-Service (PaaS) models, including cloud-based FaaS and PaaS environments. 
     The API documentation platform  110  in the present embodiment is assumed to implement at least a portion of a document repository environment accessible to the user devices  102  over the network  104 . The network  104  is assumed to comprise a portion of a global computer network such as the Internet, although other types of networks can be part of the network  104 , including a wide area network (WAN), a local area network (LAN), a satellite network, a telephone or cable network, a cellular network, a wireless network such as a WiFi or WiMAX network, or various portions or combinations of these and other types of networks. The network  104  in some embodiments therefore comprises combinations of multiple different types of networks each comprising processing devices configured to communicate using Internet Protocol (IP) or other related communication protocols. 
     As a more particular example, some embodiments may utilize one or more high-speed local networks in which associated processing devices communicate with one another utilizing Peripheral Component Interconnect express (PCIe) cards of those devices, and networking protocols such as InfiniBand, Gigabit Ethernet or Fibre Channel. Numerous alternative networking arrangements are possible in a given embodiment, as will be appreciated by those skilled in the art. 
     The API documentation platform  110 , on behalf of respective infrastructure tenants each corresponding to one or more users associated with respective ones of the user devices  102 , implements a document generation engine  140  to perform API documentation generation. According to an embodiment, the infrastructure tenants are cloud infrastructure tenants. By way of example, the document generation services are assumed to include the establishment of a document corpus  200  comprising a versioned database for API related sources and reference documentations, dynamic updating of API information sets and query driven real-time and custom document generation on behalf of each of one or more users associated with respective user devices  102 . 
     The API documentation platform  110  in some embodiments may be implemented as part of a cloud infrastructure in the form of a cloud-based system such as an AWS system. Other examples of cloud-based systems that can be used to provide at least portions of the API documentation platform  110  and possibly other portions of system  100  include GCE, and Microsoft Azure®. 
     In accordance with an embodiment of the present invention, the API documentation platform  110  provides automated tools for creating a centralized location for API related source and reference information, removing inconsistency across API documentation across different products, improving accessibility of the API documentation by tagging accurate content and key phrases for task-based queries, and providing a common user interface (UI) when reference material may be coming from multiple formats via different source code. Conventional techniques, which cannot be applied across varied input formats, do not allow for the generation and customization of API documentation, and are not able to keep pace with the dynamic nature of API revisions and updates. 
     The API documentation platform  110  in the embodiment of  FIG. 1  illustratively comprises a document classifier  120 , which outputs a plurality of classified API documents to a document corpus  200 . In accordance with an embodiment of the present invention, the document classifier  120  receives as inputs from multiple sources a plurality of API documents respectively configured as electronic files in a variety of input formats. The input formats include, but are not necessarily limited to, extensible markup language (XML), JavaScript Object Notation (JSON), Pydoc, Microsoft Word®, txt, source code, or any other intelligible format. 
     The input sources include an internal document source (e.g., from within an enterprise supplying an API or API documentation), which includes, for example, an internal document cloud environment  109 , and an external document source (e.g., from outside of an enterprise supplying an API or API documentation), which includes, for example, an external document cloud  107 , such as, an open source cloud environment. In accordance with an embodiment of the present invention, the internal document cloud environment  109  can include, but is not necessarily limited to, documents from different lines-of-business (LOBs)  106 - 1 ,  106 - 2 , . . . ,  106 -N, and a number of API documents based on, for example, a number of API products, a number of product versions, a number of document releases, and a number of types of product documents. The external document cloud environment  107  can include, but is not necessarily limited to, API documents from external databases of documentation files, and from social media sources, such as, for example, blogs, forums, and question and answer websites. Like the internal document cloud environment  109 , the external document cloud environment  107  can include, but is not necessarily limited to documents from different LOBs, and the number of API documents can be based on, for example, a number of API products, product versions, document releases, and types of product documents. Similar to the external document cloud environment  107 , the internal document cloud environment  109  can include, but is not necessarily limited to, internal databases of documentation files, and internal blogs, forums, and question and answer sites. 
     A plurality of classified API documents are output from the document classifier  120  to the document corpus  200 . The classified documents are classified based on, for example, common API definitions and metadata, corresponding to, for example, API operations, parameters, and schema patterns. The classification accurately organizes API documentation based on API types or specified workflows for usage scenarios. Examples of a document classifier  120  and techniques for document classification are disclosed in U.S. patent application Ser. No. 16/041,353, filed on Jul. 20, 2018 and entitled “Identification and Curation of Application Programming Interface Data from Different Sources,” which is incorporated by reference herein. 
     The document corpus  200  includes a collection of various formatted API documents stored in one or more databases. The various API documents are not necessarily related. Indexing in the document corpus  200  is performed using, for example inverted files, which are files that are indexed on attributes of the data itself. In accordance with some embodiments of the present invention, the API documentation platform  110  computes a Term-Document (T-D) matrix from the index, which describes the frequency of terms that occur in the collection of documents. Then, the API documentation platform  110  computes highly correlated terms using one or more approaches. For example, a high degree of correlation within the document corpus is achieved by performing Latent Semantic Analysis (LSA) on the T-D matrix. 
     In more detail, referring to  FIG. 2 , the document corpus  200  is a versioned database for API related sources and reference documentation, and includes versioned data  205  so that distinctions can be made between versions of APIs and API documents. According to some embodiments, a plurality of application programming interface electronic documents in the document corpus  200  are organized according to one or more application programming interface versions. The documents in the document corpus  200  are organized based on, for example, API information and metadata  230 , corresponding to, for example, API schema documents  210 , management domain metadata  212  and static data  214  from, for example, tables, diagrams and error messages associated with different APIs and API references. The document corpus  200  includes a database manager  220  configured to process inputs based on the API schema documents  210 , management domain metadata  212  and static data  214 , and organize and manage the inputs into the formatted API information and metadata  230  using, for example, inverted file indexing, T-D matrix computation and highly correlated term computation. API schema documents  210  refer to, for example, formatted documents for APIs, such as web services description language (WSDL)/managed object format (MOF) (for Web Services for Management (WSMAN)), conceptual schema definition language (CSDL) (for Redfish®), etc. Management domain metadata  212  refers to, for example, data required to organize and/or manage the APIs into logical sets, such as data regarding to which profile and/or workflow an API belongs. Static data  214  refers to, for example, information related to APIs, such as, for example, diagrams explaining a profile and/or workflow, and/or some generic tables that include mappings of standard return codes to extended description mapping, etc. 
     Referring to  FIGS. 1 and 2 , a query formatter  130  formats queries received from one or more users (via user devices  102 ) seeking information in the form of API documentation corresponding to one or more APIs. To generate a desired documentation set, the query formatter  130  sends formatted queries to the document generation engine  140 . Formatted queries may call out user requested information such as, for example, API Generation/Version, API name/type, supported document format, storage versions, and/or content type. Some non-limiting examples of formatted queries include, but are not limited to, 14G+Redfish®+API format: pdf, Open Manage API format: json, 14G+Redfish®+API SubContent: Storage version: Current. 
     The query formatter  130  can create customized queries depending upon the requirements of document to be generated. Queries can include sub-categorization when a subset of the document corpus  200  is required. As noted above, the query can also include the version, and specify, for example, a version number (e.g., 14G indicating 14 th  generation). 
     The query formatter  130  can further add a version-diff flag to the user query requesting generation of a document set which will show the differences between two provided versions of an API. 
     According to one or more embodiments of the present invention, the query may request API documentation to be in one or more supported document formats depending on user system specifications and/or needs of the users of the user devices  102 . The supported document formats include, but are not necessarily limited to, hypertext markup language (HTML), portable document format (PDF) and/or JavaScript Object Notation (JSON). Accordingly, embodiments of the present invention can generate API documentation in one or more desired formats. 
     Queries can be received in plaintext form and/or via one or more forms having fields within which a user can select filters on which the query is to be based. Queries may also seek task-based API information, for example, referring to documentation related to a workflow, for instance, discovering or performing a particular type of monitoring, etc. 
     The document generation engine  140  of the API documentation platform  110  includes a query execution engine  141  comprising a search engine  143 . According to one or more embodiments of the present invention, the search engine  143  is configured to execute query expansion by performing the certain operations on the document corpus  200 . For example, the search engine  143  uses the highly correlated terms obtained from the document corpus  200  for automatic query expansion (AQE) in the search engine  143 . As a result, a search query Q will be expanded to Q′ internally, where Q′ will include extra terms related to Q, which will enhance the search results. For example, an AQE algorithm may expand a query indicating a version and general category of API, such as 14 th  generation integrated Dell Remote Access Controller APIs (14G iDRAC APIs) to specify APIs within the general API category, such as “14G iDRAC APIs wsman Redfish® racadm,” which will enhance the search results. 
     In one or more embodiments, the search engine  143  also utilizes a ranking algorithm which ranks query results corresponding to a later date higher than query results corresponding to an earlier date, or employs some other specified ranking criteria. Such a ranking algorithm may be useful for distinguishing documentation based on documentation or API version. The search engine algorithms may incorporate one or more machine learning techniques. In general, machine learning techniques and components used in accordance with embodiments of the present invention may include, but are not necessarily limited to, neural networks, a Support Vector Machine (SVM), a Multilayer Perceptron (MLP), a deep learning model, decision trees, and clustering. 
     Once the query execution engine  141  parses a query, as explained in more detail herein below, the requested documentation based, for example, on the highest ranked query results, is retrieved from the document corpus  200  and a desired output is created. For multiple API or API documentation versions, data will be retrieved from versioned databases in the document corpus  200 . 
     The document generation engine  140  of the API documentation platform  110  includes a document summarizer  145 . According to one or more embodiments of the present invention, the document summarizer  145  is configured to take as input a set of documents based on the query results, and generate summaries for the documents based on multiple topics corresponding to industry standard approaches. For example, the topics include, but are not necessarily limited to, reference API documentation, class level documentation, domain oriented documentation, and/or workflow usage scenario documentation. The document summarizer  145  outputs the document summaries in a structured custom format, which may then be transformed into known standard formats (e.g., HTML, PDF, etc.) for user consumption. A structured custom format refers to, for example, an implementation specific format which can capture any API related information, which can further be used to generate formatted publishable documents in various formats (e.g., CSDL/WSDL/MOFs/PyDoc→structured custom format→API published documents in various formats (e.g., HTML, PDF, etc.). 
     The document generation engine  140  of the API documentation platform  110  includes a build environment  300  comprising a document formatter  400 . According to one or more embodiments of the present invention, in response to one or more queries, the build environment  300  is configured to generate a subset of the plurality of API electronic documents in the document corpus  200  using one or more code artifacts. The code artifacts comprise, but are not necessarily limited to, MOF and management information base (MIB) code artifacts. 
     Referring to  FIG. 3 , in generating the subset of API documentation in response to a query, a compiler  310  retrieves relevant documentation files from a code base component  305 . The files include, but are not necessarily limited to, MOF files, MIB files, and/or other code artifacts which are rich in documentation sources. The compiler  310  also retrieves version information  315  corresponding to the one or more API versions from documentation sources in the document corpus  200 . The compiler  310  compiles the documentation files from a code base component  305  and the retrieved version information  315  and transmits the compiled data to a data extraction component  325 . Based on specified release versions in the one or more queries, the data extraction component  325  extracts appropriate attributes and diagrams from an attribute registry  330  and error messages from an error message registry  320 . The extracted data is relevant to the release versions specified in the one or more queries. 
     The information retrieved by the compiler  310  and the data extraction component  325  is processed by a documentation database manager (DDM)  335 . The DDM  335  includes necessary artificial intelligence to create, update and/or delete appropriate table entries in one or more databases  351 - 1 ,  351 - 2 , . . . ,  351 -Z respectively corresponding to various APIs, such as, for example, WSMAN, Representational State Transfer (REST), Simple Network Management Protocol (SNMP), RACADM (Remote Access Controller Admin), etc. The databases  351 - 1 ,  351 - 2 , . . . ,  351 -Z are part of a webserver environment  350  of the API documentation platform  110 , which is accessible to, for example, querying users via user devices  102  and web crawlers. The webserver environment  350  is used by server-side scripting languages to create pages on demand. The documentation databases  351 - 1 ,  351 - 2 , . . . ,  351 -Z will remain staged (e.g., limited to internal access by, for example, validation engineers of an organization administering the API documentation platform  110 ) until a public release to customers is performed. Documentation from the staged database may be used by the developers and/or testers of an organization administering the API documentation platform  110 . The released databases  351 - 1 ,  351 - 2 , . . . ,  351 -Z will be open to the customers who can download documentation in any desired supported format, such as, for example, HTML, PDF, JSON, etc. The intelligence of the DDM  335  is achieved by execution of one or more machine learning techniques noted herein above. 
     In one or more embodiments of the present invention, the DDM  335  is configured to dynamically modify one or more of the API electronic documents in the document corpus  200  based on the retrieved API version data, and create new entries or update the databases  351 - 1 ,  351 - 2 , . . . ,  351 -Z with the version information to enable documentation generation based on the API versions. 
     In response to the one or more queries, a subset of the documentation from the document corpus  200  is transmitted to the user devices  102  of one or more users via the webserver environment  350  and the network  104 . The build environment  300  includes a document formatter  400 , which formats the API documentation provided to the users in any desired supported format, such as, for example, HTML, PDF, JSON, etc. Referring to  FIG. 4 , a non-limiting example of a document formatter  400  formats API documentation in HTML, XML, and PDF formats  441 ,  442  and  444  for an end user on a user device  102 . The document formatter  400  creates a profile API database  420  from multiple code artifacts  410  and profile specific metadata  415 . The profile database  420  includes, for example, profiles for different API generations and/or versions. The code artifacts  410  include, for example, MOF files, MIB files, and/or other code artifacts which are rich in documentation sources. The profile specific metadata  415  refers to, for example, metadata corresponding to respective profiles, such as storage management, thermal management, network management, etc., which are used, for example, in WSMan documentation, where the concept of profiles is utilized. 
     Based on the query received from a user, the document formatter  400  will generate the desired documentation in the one or more formats  441 ,  442  and  444 . The formats  441 ,  442  and  444  may be derived from scripts  432  and  433  based on different programming languages. The document formatter  400  is configured to process files into these scripts, and then transform the scripts into the desired formats  441 ,  442  and  444 . In some embodiments, programming language  1  script  432  corresponds to PHP: Hypertext Preprocessor scripting language, and programming language  2  script  433  Python™ corresponds to programming language. As shown in  FIG. 4 , the document formatter  400  derives HTML and XML formats  441  and  442  from the programming language  1  script  432 , and XML, LaTex and PDF formats  442 ,  443  and  444  from programming language  2  script  433 . The document formatter  400  further comprises a LaTex compiler  424  to transform the documentation in LaTex format  443  to PDF format  444 . 
     The document classifier  120 , query formatter  130 , document generation engine  140 , document corpus  200 , webserver environment  350 , and other components of the API documentation platform  110  comprise further hardware and software required for running the API documentation platform  110 , including, but not necessarily limited to, on-premises or cloud-based centralized hardware, graphics processing unit (GPU) hardware, virtualization infrastructure software and hardware, Docker containers, networking software and hardware, and cloud infrastructure software and hardware. 
     The databases or cloud environments discussed herein (e.g., document corpus  200 , databases  351 - 1 ,  351 - 2 , . . . ,  351 -Z and profile database  420 ) may comprise a database service, such as, but not necessarily limited to GCE Cloud Storage, Microsoft Azure Blob (Binary Large Object) Storage, DynamoDB, MongoDB, Amazon Aurora and Oracle database. 
     The document generation performed by the API documentation platform  110  can be performed based on real-time data from multiple sources retrieved over the network(s)  104 , so that the information processing system can react to events as they happen. For example, the input data sources may include API document updates reflecting, for example, new API products, new API product versions or modifications and/or new or modified API guide releases captured in real-time, which may be processed by the API documentation platform  110  to generate API documentation for the end users of the user devices  102  reflecting real-time API and API documentation updates. 
     Although the document classifier  120 , query formatter  130 , document generation engine  140 , document corpus  200 , webserver environment  350 , and other components of the API documentation platform  110  in the present embodiment are shown as part of the API documentation platform  110 , at least a portion of document classifier  120 , query formatter  130 , document generation engine  140 , document corpus  200 , webserver environment  350 , and other components of the API documentation platform  110  in other embodiments may be implemented on one or more other processing platforms that are accessible to the API documentation platform  110  over one or more networks. Such components can each be implemented at least in part within another system element or at least in part utilizing one or more stand-alone components coupled to the network  104 . 
     The databases described herein are assumed to comprise one or more storage systems configured to store information relating to processing performed, data used, and to other functionality of the API documentation platform  110 . Such storage systems can comprise any of a variety of different types of storage including network-attached storage (NAS), storage area networks (SANs), direct-attached storage (DAS) and distributed DAS, as well as combinations of these and other storage types, including software-defined storage. 
     Other particular types of storage products that can be used in implementing a given storage system of API documentation platform  110  in an illustrative embodiment include VNX® and Symmetrix VMAX® storage arrays, flash hybrid storage products such as Unity™, software-defined storage products such as ScaleIO™ and ViPR®, cloud storage products such as Elastic Cloud Storage (ECS), object-based storage products such as Atmos®, scale-out all-flash storage arrays such as XtremIO®, and scale-out NAS clusters comprising Isilon® platform nodes and associated accelerators, all from Dell EMC. Combinations of multiple ones of these and other storage products can also be used in implementing a given storage system in an illustrative embodiment. 
     It is assumed that the API documentation platform  110  in the  FIG. 1  embodiment and other processing platforms referred to herein are each implemented using a plurality of processing devices each having a processor coupled to a memory. Such processing devices can illustratively include particular arrangements of compute, storage and network resources. For example, processing devices in some embodiments are implemented at least in part utilizing virtual resources such as virtual machines (VMs) or Linux containers (LXCs), or combinations of both as in an arrangement in which Docker containers or other types of LXCs are configured to run on VMs. 
     The term “processing platform” as used herein is intended to be broadly construed so as to encompass, by way of illustration and without limitation, multiple sets of processing devices and one or more associated storage systems that are configured to communicate over one or more networks. 
     As a more particular example, document classifier  120 , query formatter  130 , document generation engine  140 , document corpus  200 , webserver environment  350 , and other components of the API documentation platform  110 , and the elements thereof can each be implemented in the form of one or more LXCs running on one or more VMs. Other arrangements of one or more processing devices of a processing platform can be used to implement document classifier  120 , query formatter  130 , document generation engine  140 , document corpus  200 , webserver environment  350 , as well as other components of the API documentation platform  110 . Other portions of the system  100  can similarly be implemented using one or more processing devices of at least one processing platform. 
     Distributed implementations of the system  100  are possible, in which certain components of the system reside in one data center in a first geographic location while other components of the system reside in one or more other data centers in one or more other geographic locations that are potentially remote from the first geographic location. Thus, it is possible in some implementations of the system  100  for different portions of the API documentation platform  110  to reside in different data centers. Numerous other distributed implementations of the API documentation platform  110  are possible. 
     Accordingly, one or each of the document classifier  120 , query formatter  130 , document generation engine  140 , document corpus  200 , webserver environment  350 , and other components of the API documentation platform  110  can each be implemented in a distributed manner so as to comprise a plurality of distributed components implemented on respective ones of a plurality of compute nodes of the API documentation platform  110 . 
     It is to be appreciated that these and other features of illustrative embodiments are presented by way of example only, and should not be construed as limiting in any way. 
     Accordingly, different numbers, types and arrangements of system components such as the document classifier  120 , query formatter  130 , document generation engine  140 , document corpus  200 , webserver environment  350 , and other components of the API documentation platform  110 , and the elements thereof can be used in other embodiments. 
     It should be understood that the particular sets of modules and other components implemented in the system  100  as illustrated in  FIG. 1  are presented by way of example only. In other embodiments, only subsets of these components, or additional or alternative sets of components, may be used, and such components may exhibit alternative functionality and configurations. 
     For example, as indicated previously, in some illustrative embodiments, functionality for the API documentation platform can be offered to cloud infrastructure customers or other users as part of FaaS and/or PaaS offerings. 
     The operation of the information processing system  100  will now be described in further detail with reference to the flow diagram of  FIG. 5 . The process  500  as shown includes steps  501  through  511 , and is suitable for use in the system  100  but is more generally applicable to other types of information processing systems comprising an API documentation platform configured for generating and dynamically updating API documentation from different source files. 
     In step  501 , the process  500  includes generating a document corpus comprising a plurality of API electronic documents. The plurality of API electronic documents are organized according to one or more API versions. 
     In step  503 , a query is received from one or more users seeking information corresponding to one or more APIs. In accordance with one or more embodiments of the present invention, the query is formatted based on the one or more supported document formats. A flag can be generated for the query to seek a documentation set which illustrates differences between at least two of API versions. 
     In some embodiments, the process includes indexing of the document corpus, and computation of a T-D matrix from the index. Highly correlated terms of the electronic documents in the document corpus are computed via analysis of the T-D matrix. By employing an AQE algorithm, the query is expanded using the highly correlated terms. 
     In step  505 , in response to the query, a subset of the plurality of API electronic documents is generated using one or more code artifacts. The code artifacts comprise, for example, MOF and MIB code artifacts. 
     In step  507 , data corresponding to the one or more API versions is retrieved. The retrieved API version data comprises, for example, error messages and/or supported attributes relevant to at least one of the API versions. In step  509 , one or more of the plurality of API electronic documents in the subset of the plurality of API electronic documents is dynamically modified based on the retrieved API version data. In dynamically modifying the one or more of the plurality of API electronic documents in the subset, one or more table entries in one or more databases specific to one or more APIs is created, updated and/or deleted. 
     In step  511  the subset of the plurality of API electronic documents is transmitted to the one or more users in response to the query. Prior to receipt of the subset of API electronic documents, the documents are transformed from one or more document formats into one or more supported document formats for consumption by one or more on the user devices. 
     A ranking algorithm may be employed which ranks electronic documents of the plurality of API electronic documents corresponding to a later date higher than electronic documents of the plurality of API electronic documents corresponding to an earlier date. 
     It is to be appreciated that the  FIG. 5  process and other features and functionality described above can be adapted for use with other types of information systems configured to execute document generation services on an API documentation platform or other type of processing platform. 
     The particular processing operations and other system functionality described in conjunction with the flow diagram of  FIG. 5  are therefore presented by way of illustrative example only, and should not be construed as limiting the scope of the disclosure in any way. Alternative embodiments can use other types of processing operations. For example, the ordering of the process steps may be varied in other embodiments, or certain steps may be performed at least in part concurrently with one another rather than serially. Also, one or more of the process steps may be repeated periodically, or multiple instances of the process can be performed in parallel with one another. 
     Functionality such as that described in conjunction with the flow diagram of  FIG. 5  can be implemented at least in part in the form of one or more software programs stored in memory and executed by a processor of a processing device such as a computer or server. As will be described below, a memory or other storage device having executable program code of one or more software programs embodied therein is an example of what is more generally referred to herein as a “processor-readable storage medium.” 
     Illustrative embodiments of systems with an API documentation platform as disclosed herein can provide a number of significant advantages relative to conventional arrangements. For example, embodiments of the present invention are configured to address problems with creating a unified set of API documentation from different sets of source documents and dynamically changing the reference documentation in case of any updates to the APIs and/or API documents. Currently, there are no techniques or solutions which provide a centralized location to search for, design and retrieve APIs for different products. Furthermore, there are no techniques or solutions which allow for automatic and real-time updates to keep pace with API evolution, updates and upgrades. 
     As an advantage, embodiments of the present invention permit classified API documents to be stored in an open-source centralized repository for API related source and reference information, so that inconsistency can be removed across API documentation across different products. In another advantage, embodiments of the present invention improve accessibility of the API documentation by formatting and expanding queries, by organizing, updating and retrieving documentation according to API versions, and by providing a webserver environment through which users can specify documentation format, and retrieve documentation from interface specific databases. In another advantage, embodiments of the present invention provide a unified platform to avoid any conflicts among different API product lines, which can simultaneously produce API documents having a unified format for different API products. 
     Conventional computer driven techniques for generation of API documentation result in inconsistencies between API documentation across different products. Currently, there is no mechanism for generating API documentation in multiple formats via different source code, and for capturing data reflecting real-time updates for APIs and API documents. Conventional techniques also fail to provide task-based API information. 
     Presently, there are no processes for establishing a versioned database for API related sources and reference documentation, dynamic updating of API information sets, or real-time and custom API document generation. 
     Advantageously, the embodiments of the present invention deliver a unified solution that can be implemented on any set of APIs to automatically generate harmonized API documentation, even though API structures are different for different products. Conventional tools are custom-made for a specific type of inputs. However, the document generation structure of the API documentation platform of the embodiments of the present invention can consume content from any type of input file and generate API guides in multiple formats. 
     The embodiments of the present invention advantageously ensure accessibility of API documentation across web searches by generating action/task driven reference documents via appropriate tagging, and ensure the same overall appearance for API documentation sets irrespective of the variation in source code or content type. By providing for dynamic and real-time updates to API documentation and databases, and seeking out version and error message information, the embodiments of the present invention also ensure that customers will receive the latest set of API reference guides, even if there are minimum changes in the API sets. Embodiments of the present invention extending search functionality so that users can generate custom documents for their own specific requirements and formats. With the disclosed embodiments, different formats of documents are automatically generated from the same underlying information sources and databases. 
     It is to be appreciated that the particular advantages described above and elsewhere herein are associated with particular illustrative embodiments and need not be present in other embodiments. Also, the particular types of information processing system features and functionality as illustrated in the drawings and described above are exemplary only, and numerous other arrangements may be used in other embodiments. 
     As noted above, at least portions of the information processing system  100  may be implemented using one or more processing platforms. A given such processing platform comprises at least one processing device comprising a processor coupled to a memory. The processor and memory in some embodiments comprise respective processor and memory elements of a virtual machine or container provided using one or more underlying physical machines. The term “processing device” as used herein is intended to be broadly construed so as to encompass a wide variety of different arrangements of physical processors, memories and other device components as well as virtual instances of such components. For example, a “processing device” in some embodiments can comprise or be executed across one or more virtual processors. Processing devices can therefore be physical or virtual and can be executed across one or more physical or virtual processors. It should also be noted that a given virtual device can be mapped to a portion of a physical one. 
     Some illustrative embodiments of a processing platform that may be used to implement at least a portion of an information processing system comprise cloud infrastructure including virtual machines and/or container sets implemented using a virtualization infrastructure that runs on a physical infrastructure. The cloud infrastructure further comprises sets of applications running on respective ones of the virtual machines and/or container sets. 
     These and other types of cloud infrastructure can be used to provide what is also referred to herein as a multi-tenant environment. One or more system components such as the API documentation platform  110  or portions thereof are illustratively implemented for use by tenants of such a multi-tenant environment. 
     As mentioned previously, cloud infrastructure as disclosed herein can include cloud-based systems such as AWS, GCE and Microsoft Azure. Virtual machines provided in such systems can be used to implement at least portions of one or more of a computer system and an API documentation platform in illustrative embodiments. These and other cloud-based systems in illustrative embodiments can include object stores such as AWS S3, GCE Cloud Storage, and Microsoft Azure Blob Storage. 
     Illustrative embodiments of processing platforms will now be described in greater detail with reference to  FIGS. 6 and 7 . Although described in the context of system  100 , these platforms may also be used to implement at least portions of other information processing systems in other embodiments. 
       FIG. 6  shows an example processing platform comprising cloud infrastructure  600 . The cloud infrastructure  600  comprises a combination of physical and virtual processing resources that may be utilized to implement at least a portion of the information processing system  100 . The cloud infrastructure  600  comprises multiple virtual machines (VMs) and/or container sets  602 - 1 ,  602 - 2 , . . .  602 -L implemented using virtualization infrastructure  604 . The virtualization infrastructure  604  runs on physical infrastructure  605 , and illustratively comprises one or more hypervisors and/or operating system level virtualization infrastructure. The operating system level virtualization infrastructure illustratively comprises kernel control groups of a Linux operating system or other type of operating system. 
     The cloud infrastructure  600  further comprises sets of applications  610 - 1 ,  610 - 2 , . . .  610 -L running on respective ones of the VMs/container sets  602 - 1 ,  602 - 2 , . . .  602 -L under the control of the virtualization infrastructure  604 . The VMs/container sets  602  may comprise respective VMs, respective sets of one or more containers, or respective sets of one or more containers running in VMs. 
     In some implementations of the  FIG. 6  embodiment, the VMs/container sets  602  comprise respective VMs implemented using virtualization infrastructure  604  that comprises at least one hypervisor. Such implementations can provide document generation functionality of the type described above for one or more processes running on a given one of the VMs. For example, each of the VMs can implement user specific layout management, document theme analysis, document management and/or feedback and training for one or more processes running on that particular VM. 
     An example of a hypervisor platform that may be used to implement a hypervisor within the virtualization infrastructure  604  is the VMware® vSphere® which may have an associated virtual infrastructure management system such as the VMware® vCenter™. The underlying physical machines may comprise one or more distributed processing platforms that include one or more storage systems. 
     In other implementations of the  FIG. 6  embodiment, the VMs/container sets  602  comprise respective containers implemented using virtualization infrastructure  604  that provides operating system level virtualization functionality, such as support for Docker containers running on bare metal hosts, or Docker containers running on VMs. The containers are illustratively implemented using respective kernel control groups of the operating system. Such implementations can provide document generation functionality of the type described above for one or more processes running on different ones of the containers. For example, a container host device supporting multiple containers of one or more container sets can implement one or more instances of user specific layout management, document theme analysis, document management and/or feedback and training. 
     As is apparent from the above, one or more of the processing modules or other components of system  100  may each run on a computer, server, storage device or other processing platform element. A given such element may be viewed as an example of what is more generally referred to herein as a “processing device.” The cloud infrastructure  600  shown in  FIG. 6  may represent at least a portion of one processing platform. Another example of such a processing platform is processing platform  700  shown in  FIG. 7 . 
     The processing platform  700  in this embodiment comprises a portion of system  100  and includes a plurality of processing devices, denoted  702 - 1 ,  702 - 2 ,  702 - 3 , . . .  702 -K, which communicate with one another over a network  704 . 
     The network  704  may comprise any type of network, including by way of example a global computer network such as the Internet, a WAN, a LAN, a satellite network, a telephone or cable network, a cellular network, a wireless network such as a WiFi or WiMAX network, or various portions or combinations of these and other types of networks. 
     The processing device  702 - 1  in the processing platform  700  comprises a processor  710  coupled to a memory  712 . The processor  710  may comprise a microprocessor, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other type of processing circuitry, as well as portions or combinations of such circuitry elements. 
     The memory  712  may comprise random access memory (RAM), read-only memory (ROM) or other types of memory, in any combination. The memory  712  and other memories disclosed herein should be viewed as illustrative examples of what are more generally referred to as “processor-readable storage media” storing executable program code of one or more software programs. 
     Articles of manufacture comprising such processor-readable storage media are considered illustrative embodiments. A given such article of manufacture may comprise, for example, a storage array, a storage disk or an integrated circuit containing RAM, ROM or other electronic memory, or any of a wide variety of other types of computer program products. The term “article of manufacture” as used herein should be understood to exclude transitory, propagating signals. Numerous other types of computer program products comprising processor-readable storage media can be used. 
     Also included in the processing device  702 - 1  is network interface circuitry  714 , which is used to interface the processing device with the network  704  and other system components, and may comprise conventional transceivers. 
     The other processing devices  702  of the processing platform  700  are assumed to be configured in a manner similar to that shown for processing device  702 - 1  in the figure. 
     Again, the particular processing platform  700  shown in the figure is presented by way of example only, and system  100  may include additional or alternative processing platforms, as well as numerous distinct processing platforms in any combination, with each such platform comprising one or more computers, servers, storage devices or other processing devices. 
     For example, other processing platforms used to implement illustrative embodiments can comprise converged infrastructure such as VxRail™, VxRack™, VxRack™ FLEX, VxBlock™, or Vblock® converged infrastructure from VCE, the Virtual Computing Environment Company, now the Converged Platform and Solutions Division of Dell EMC. 
     It should therefore be understood that in other embodiments different arrangements of additional or alternative elements may be used. At least a subset of these elements may be collectively implemented on a common processing platform, or each such element may be implemented on a separate processing platform. 
     Also, numerous other arrangements of computers, servers, storage devices or other components are possible in the information processing system  100 . Such components can communicate with other elements of the information processing system  100  over any type of network or other communication media. 
     As indicated previously, components of an information processing system as disclosed herein can be implemented at least in part in the form of one or more software programs stored in memory and executed by a processor of a processing device. For example, at least portions of the functionality of one or more components of the API documentation platform  110  are illustratively implemented in the form of software running on one or more processing devices. 
     It should again be emphasized that the above-described embodiments are presented for purposes of illustration only. Many variations and other alternative embodiments may be used. For example, the disclosed techniques are applicable to a wide variety of other types of information processing systems and API documentation platforms. Also, the particular configurations of system and device elements and associated processing operations illustratively shown in the drawings can be varied in other embodiments. Moreover, the various assumptions made above in the course of describing the illustrative embodiments should also be viewed as exemplary rather than as requirements or limitations of the disclosure. Numerous other alternative embodiments within the scope of the appended claims will be readily apparent to those skilled in the art.