JP7519230B2 - API implementation support system and API implementation support method - Google Patents

Description

The present invention relates to an API support system and an API support method.

Patent Document 1 describes an API conversion adapter that converts an existing system into an API. The API conversion adapter is placed between the existing system and an API gateway, stores a packet transmission/reception sequence with the existing system, extracts parameters in received packets, and replaces the parameters in the stored packets with the extracted parameters. The API conversion adapter accepts requests and returns responses with the API gateway using REST, and transmits and receives data with the existing system using an existing protocol.

JP 2017-54411 A

In recent years, Web APIs (Web Application Programming Interfaces) have been provided in many Web applications (hereinafter referred to as "Web apps").
By using I, it is possible to improve the efficiency of developing client applications (hereinafter referred to as "client applications") that work with external web applications. In addition, by using Web API, it is possible to easily realize client applications that greatly improve user convenience (for example, when creating a nationwide version of a client application using Web APIs provided by each local government).

Providing a web application as a web API in this way has many advantages, but turning an existing web application (hereafter referred to as an "existing web application") into an API usually requires a lot of work. In addition, it is difficult to give someone else's existing web application the functionality to turn it into an API unless you have the necessary permissions.

The technology described in Patent Document 1 aims to turn an existing system into an API without modifying the existing Web application by creating an API conversion adapter using a pre-stored packet transmission/reception sequence as input, as a method of making the existing system into an API without modifying the existing Web application. To create the API conversion adapter, parameters in the received packet (parts to be changed as an API request) are extracted/replaced. However, the technology described in Patent Document 1 is based on the premise that a packet transmission/reception sequence with the existing Web application already exists, and does not specifically disclose any technology to reduce the amount of work required to design API specifications.

The present invention was made against this background, and aims to provide an API conversion support system and an API conversion support method that can support the work involved in API conversion of applications.

One aspect of the present invention for solving the above problem is an API implementation support system, which is configured using an information processing device having a processor and a storage device, and includes an access procedure acquisition unit that acquires, as an access procedure, a series of operations performed via a Web browser on a Web application to be API-implemented, an API specification setting unit that generates an API specification by presenting the contents of the acquired access procedure to a user and accepting from the user settings of the API specification required for the API implementation, and an access history acquisition unit that acquires an access history, which is a history of operations performed on the Web application, wherein the access procedure acquisition unit acquires, as the access procedure, the series of operations included in the access history, and the access procedure acquisition unit classifies the access history into a plurality of groups based on at least one of those in which the subject of the operations is common and the continuity of the intervals between dates and times when the operations were performed, identifies an inclusion relationship between the plurality of groups, selects a group that is included as a candidate from which the access procedure is extracted, and acquires, as the access procedure, the series of operations included in the selected candidate group.

Other problems and solutions disclosed in this application will be made clear in the detailed description of the invention and the drawings.

The present invention can assist with the work involved in making applications into APIs.

1 is a diagram illustrating a schematic configuration of an information processing system according to a first embodiment. 1 is a configuration example of an information processing device used in the configuration of an information processing system. 13 is an example of an API specification setting screen. 13 is an example of an API specification setting screen (an example in which values are set in setting fields). 1 is an example of an API specification. 13 is an example of a response from a Web API. FIG. 11 is a diagram illustrating a schematic configuration of an information processing system according to a second embodiment. 13 is an example of an access history. 13 is a flowchart illustrating an access procedure extraction process. This is an example of dividing the access history. This is an example of dividing the access history. This is an example of dividing the access history. FIG. 13 is a diagram illustrating a schematic configuration of an information processing system according to a third embodiment. 13 is an example of an API specification setting screen. 13 is an example of a Web API information search screen. 13 is an example of an access procedure display screen.

The following describes in detail an embodiment of the present invention with reference to the drawings. Note that the following description and drawings are merely examples for explaining the present invention, and have been omitted or simplified as appropriate for clarity of explanation. The present invention can also be implemented in various other forms. Unless otherwise specified, each component may be singular or plural.

In the following explanation, the same or similar components may be given the same reference numerals and duplicate explanations may be omitted. In the following explanation, the letter "S" before a reference numeral denotes a processing step. Various information (data) in the following explanation may be represented or managed in a manner other than the data structure shown as an example. When explaining various types of identification information, expressions such as "identifier" and "ID" are used as appropriate, but these are interchangeable.

In the following description, a Web application that provides a Web service is referred to as a "Web application," and an application that uses a Web API (Web Application Programming Interface) is referred to as a "Web API-using application."

[First embodiment]
FIG. 1 shows a schematic configuration of an information processing system according to a first embodiment (hereinafter referred to as "API implementation support system 1"). The API implementation support system 1 includes an API implementation support device 100, an existing Web server 200, an API adapter 300, and a Web API utilization device 400. Each of these devices is configured using one or more information processing devices (computers), and is connected in a state in which two-way communication is possible via a communication network 5. The communication network 5 may be, for example, a LAN (Local Area Network), a WAN (Wide Area Network), or the like.
a Network), the Internet, dedicated lines, public communication networks, etc.

The API implementation support device 100 converts an existing Web application (hereinafter, referred to as "existing Web application 210") in an existing Web server 200 into a Web API, that is, makes it available as a Web API via a communication network 5. The API implementation support device 100 acquires an access procedure 111 that is an access procedure of the existing Web application 210 from operation information obtained when a Web API builder 2, who is a user who performs the Web API implementation, accesses the existing Web application 210 using a Web browser, and generates an API specification 112 that is information required to convert the existing Web application into a Web API based on the acquired access procedure 111. The API specification 112 is described in a format such as "GraphQL Schema" or "OpenAPI Specification". However, the API specification 112 may be described in another type of format.

The existing web server 200 functions, for example, as an information processing device (web server) that provides a web service by an existing web application 210 to an information processing device that accesses it via the communication network 5.

Based on the access procedure 111 and API specifications 112 provided by the API implementation support device 100, the API adapter 300 provides the usage environment of a Web API (hereinafter referred to as "Web API (existing Web application)") that has been implemented by implementing an existing Web application to the Web API utilization device 400 via the communication network 5.

An application (hereinafter referred to as "Web API using application 410") that uses a Web API (existing Web application) runs on the Web API using device 400. The Web API using application 410 provides a Web service to other information processing devices, for example, via a communication network 5. Note that the Web API user 3, who is the user of the Web API using application 410, may be the same person as the Web API builder 2.

2 is a hardware configuration example of an information processing device used to realize the components of the API support system 1, that is, the API support device 100, the existing Web server 200, the API adapter 300, and the Web API utilization device 400. The illustrated information processing device 10 includes a processor 11, a main memory device 12, an auxiliary memory device 13, an input device 14, an output device 15, and a communication device 16. The illustrated information processing device 10 may be realized in whole or in part using virtual information processing resources provided using virtualization technology, process space separation technology, or the like, such as a virtual server provided by a cloud system. In addition, all or in part of the functions provided by the information processing device 10 may be realized by a service provided by the cloud system via an API, for example. The API support system 1 may also be configured using multiple information processing devices 10 connected to each other so as to be able to communicate with each other.

In the figure, the processor 11 is, for example, a CPU (Central Processing Unit),
PU (Micro Processing Unit), GPU (Graphics Processing Unit), FPGA (Field Programmable Gate Array), ASIC (Application Specific Integrated Circuit)
), AI (Artificial Intelligence) chips, etc.

The main memory device 12 is a device for storing programs and data, and is, for example, a ROM (Read Only Memory).
Only Memory), RAM (Random Access Memory), NVRAM (Non Volatile RAM), etc.

The auxiliary storage device 13 is, for example, a solid state drive (SSD), a hard disk drive, an optical storage device (CD (Compact Disc), DVD (Digital Versatile Disc), etc.), a storage system, an IC card, a read/write device for a recording medium such as an SD card or an optical recording medium, a storage area of a cloud server, etc. Programs and data can be read into the auxiliary storage device 13 via a recording medium reader or a communication device 16. The programs and data stored (memorized) in the auxiliary storage device 13 are read into the main storage device 12 as needed.

The input device 14 is an interface that accepts input from the outside, and is, for example, a keyboard, a mouse, a touch panel, a card reader, a pen-input tablet, a voice input device, etc.

The output device 15 is an interface that outputs various information such as the progress of processing and the results of processing. The output device 15 is, for example, a display device (liquid crystal monitor, LCD (Liquid Crystal Display), graphic card, etc.) that visualizes the various information described above, a device that converts the various information described above into audio (audio output device (speaker, etc.)), or a device that converts the various information described above into text (printer, etc.). Note that, for example, the information processing device 10 may be configured to input and output information to and from other devices via the communication device 16.

The input device 14 and output device 15 constitute a user interface that accepts information from the user and presents information.

The communication device 16 is a device that realizes communication with other devices. The communication device 16 is a wired or wireless communication interface that realizes communication with other devices via the communication network 5, and is, for example, a NIC (Network Interface Card), a wireless communication module, a USB module, etc.

The information processing device 10 may be equipped with, for example, an operating system, a file system, a DBMS (DataBase Management System) (relational database, NoSQL, etc.), a KVS (Key-Value Store), etc.

Each function of the API support system 1 is realized by the processor 11 reading and executing a program stored in the main memory device 12, or by the hardware (FPGA, ASIC, AI chip, etc.) that constitutes the API support system 1. The API support system 1 stores the various information (data) described above, for example, as a database table or a file managed by a file system.

Returning to FIG. 1, as shown in the figure, the API implementation support device 100 has the functions of a memory unit 110, an access procedure acquisition unit 120, an API specification setting unit 130, and an information transmission unit 140. These functions are realized by the processor 11 of the information processing device 10 constituting the API implementation support device 100 reading and executing a program stored in the main memory device 12, or by hardware (FPGA, ASIC, AI chip, etc.) provided in the information processing device 10 constituting the API implementation support device 100. The above programs may be stored in the main memory device 12 in advance, or may be stored in the main memory device 12 from the memory device of another device via a communication network or a portable recording medium.

Of the above functions, the memory unit 110 stores the access procedure 111 and the API specification 112.

The access procedure acquisition unit 120 provides a function for the Web API builder 2 to access the existing Web application 210 of the existing Web server 200 using a Web browser, and acquires the access procedure from operation information acquired by the Web API builder 2 accessing the existing Web application 210. Note that the operation information may be acquired by other methods such as Web scraping. The access procedure acquired by the access procedure acquisition unit 120 is stored in the storage unit 110 as the access procedure 111.

The API specification setting unit 130 accepts the setting of the API specification while presenting (displaying) the access procedure 111 to the Web API builder 2. The API specification accepted by the API specification setting unit 130 is stored in the memory unit 110 as the API specification 112.

The information transmission unit 140 transmits the access procedure 111 and API specifications 112 to the API adapter 300 via the communication network 5 at any time.

As shown in the figure, the API adapter 300 has the functions of an information receiving unit 310, a storage unit 320, an access procedure reproducing unit 330, and a Web API providing unit 340. These functions are realized by the processor 11 of the information processing device 10 constituting the API adapter 300 reading and executing a program stored in the main storage device 12, or by hardware (FPGA, ASIC, AI chip, etc.) provided in the information processing device 10 constituting the API adapter 300. The above programs may be stored in the main storage device 12 in advance, or may be stored in the main storage device 12 from a storage device of another device via a communication network or a portable recording medium.

The information receiving unit 310 receives the access procedure 111 and API specifications 112 sent from the API support device 100 via the communication network 5.

The memory unit 20 stores the access procedure 111 and API specification 112 received by the information receiving unit 310.

The access procedure reproduction unit 330 reproduces the functions of the existing Web application 210 as a Web API (existing Web application) based on the access procedure 111 and the API specification 112.

The Web API providing unit 340 provides the Web API (existing Web application) reproduced by the access procedure reproducing unit 330 to the communication network 5, i.e., provides a usage environment of the Web API (existing Web application) to an information processing device connected to the communication network 5, such as the Web API using device 400. The Web API providing unit 340 functions, for example, as an API gateway.

The Web API user 3 creates a Web API using application 410 that runs on the Web API using device 400 while using the Web API (existing Web application) provided by the API adapter 300.

<API specification settings>
The web API builder 2 can efficiently set the API specifications 112 by using a user interface provided by the API specification setting unit 130 of the API implementation support device 100 .

Figure 3A is an example of a screen (hereinafter referred to as "API specification setting screen 3000") that the API specification setting unit 130 of the API support device 100 presents to the web API builder 2 (displayed on the output device 15 (display device)) when setting the API specifications. As shown in the figure, the API specification setting screen 3000 has an access procedure display field 311, an API specification setting field (data item) 312, an API specification setting field (request name) 313, and an API specification generation instruction button 314.

The access procedure display field 311 includes multiple records having the items of operation 3111 and operation target 3112, and displays the contents of the access procedure 111 acquired by the access procedure acquisition unit 120. In addition, the Web API builder 2 can use the API specification setting field (data item) 312 and the API specification setting field (request name) 313 to set the API specifications (access procedure setting (add, edit, delete), setting the data item name (data item ID) when storing data, setting the request name, etc.).

3B shows an example in which the web API builder 2 sets specific values in the API specification setting field (data item) 312 and the API specification setting field (request name) 313 of the API specification setting screen 3000. In this example, the web API builder 2 operates a web browser to access the existing web application 210 (access the URL "https://existing-application.com"),
The access procedure 111 is displayed by performing an operation of clicking a link (whose CSS (Cascading Style Sheets) id is "userlist") that displays a user list provided on the displayed Web page. In this example, the Web API builder 2 sets in the API specification setting field (data item) 312 a data item for storing a list of user IDs and a data item for storing a list of user names, and sets a request name in the API specification setting field (request name) 313.

When the web API builder 2 has finished setting the API specifications, he or she operates the API specification generation instruction button 314. When this operation is performed, the API specification setting unit 130 generates the API specifications based on the contents set in the API specification setting field (data item) 312 and the API specification setting field (request name) 313. The generated API specifications are stored in the memory unit 110 as the API specifications 112. The information transmission unit 140 transmits the access procedure 111 and the API specifications 112 to the API adapter 300 via the communication network 5 as needed.

Figure 4A shows an example of API specification 112. The illustrated API specification 112 is written using "GraphQL SDL". The illustrated API specification 112 includes the content that when a request is made with the request name "users", a list of "User" type is returned as a response, and the "User" type has data items "id" and "name". Figure 4B is an example of a Web API response 118 (in JSON (JavaScript (registered trademark) Object Notation) format) when the API specification 112 has the content illustrated in Figure 4A.

As described above, the API implementation support device 100 presents the access procedure while accepting the setting of the API specifications from the Web API builder 2, so that the Web API builder 2 can set the API specifications 112 without having to input the access procedure, and can efficiently implement the Web API of an existing Web application.

[Second embodiment]
5 shows a schematic configuration of the API implementation support system 1 according to the second embodiment. Like the API implementation support system 1 of the first embodiment, the API implementation support system 1 of the second embodiment includes an API implementation support device 100, an existing Web server 200, an API adapter 300, and a Web API utilization device 400.

The basic configuration of the API implementation support system 1 of the second embodiment is the same as that of the API implementation support system 1 of the first embodiment, but unlike the first embodiment, the access procedure acquisition unit 120 of the API implementation support device 100 of the second embodiment extracts access procedures from an access history described below. The API implementation support device 100 of the second embodiment further includes an access history receiving unit 145. The storage unit 110 of the API implementation support device 100 of the second embodiment stores an access history 113 described below. The existing web server 200 of the second embodiment further includes an access history sending unit 220.

The API support device 100 of the second embodiment extracts the access procedure 111 from the access history 113, which is history information acquired by the existing web server 200 and generated when a user of an existing web application (hereinafter referred to as "existing web application user 4") uses a service provided by the existing web application 210. There may be one or more existing web application users 4. In addition, the access history does not necessarily have to be generated by the existing web application user 4 performing a special operation, and may be generated, for example, when the existing web application user 4 uses the service of the existing web server 200 in a normal manner.

The access history sending unit 220 of the existing web server 200 transmits the access history generated by the existing web application user 4 using the service provided by the existing web application 210 to the API support device 100 at any time.

The access history receiving unit 145 of the API implementation support device 100 receives the access history sent from the existing web server 200. The storage unit 110 stores the access history received by the access history receiving unit 145 as the access history 113. The access procedure acquisition unit 120 of the API implementation support device 100 extracts a series of operations included in the access history 113 from the access history 113 as the access procedure 111.

Figure 6 shows an example of the access history 113. The illustrated access history 113 is made up of multiple records (entries) having the following fields: record ID 1131, user ID 1132, date and time 1133, operation 1134, operation target 1135, and input value 1136. The contents of each record in the illustrated access history 113 correspond to each operation performed by the existing web application user 4 on a web page displayed in a web browser.

Of the above items, a record ID that is an identifier of the record is set in record ID 1131. A user ID that is an identifier of existing Web application user 4 is set in user ID 1132. The date and time (timestamp) when the operation was performed is set in date and time 1133. Information indicating the type (content) of the operation is set in operation 1134. Information that identifies the target of the operation (such as the location or identifier of a Web page, or an identifier of a part (object) such as a button or input field displayed on a Web page) is set in operation target 1135. A value set by existing Web application user 4 in the operation is set in input value 1136, or "-" is set if nothing is set.

For example, the records with record IDs 1131 "0001" to "0004" and "0006" in the illustrated access history 113 correspond to a series of operations in which an existing web application user 4 with a user ID of "A" accessed "https://existing-application.com" between "2020-04-01T21:00:10Z" and "2020-04-01T21:01:30Z," "opened" the web page, operated the registration button "click linkText = Register," entered "New" ("type css =.resister-box", "New"), and operated the send button "click xpath = //button ["Send"]." The access procedure acquisition unit 120 extracts such access procedures from the access history 113.

Figure 7 is a flowchart explaining the process performed by the access procedure acquisition unit 120 when extracting an access procedure (hereinafter referred to as "access procedure extraction process S700"). The access procedure extraction process S700 will be explained below with reference to this figure. Note that the following explanation takes as an example a case where the access procedure acquisition unit 120 extracts access procedures from the access history 113 according to the policy that "frequently performed usage procedures are useful access procedures that we would like to provide as APIs." However, the extraction policy is not necessarily limited to the one shown in the example.

First, the access procedure acquisition unit 120 divides each record in the access history 113 into multiple groups by user ID and date and time (S711).

Figures 8A to 8C show an example in which the records of the access history 113 illustrated in Figure 6 are divided into multiple groups by user ID and date and time. In this example, the access procedure acquisition unit 120 divides the history into separate histories when there is no history for more than one hour (when the continuity of the interval between the dates and times when operations were performed is interrupted for more than a specified time value). The division method is not necessarily limited to the example shown, and for example, the access history 113 may be divided by session based on the session information of the existing Web application user 4.

In this example, the access procedure acquisition unit 120 divides the access history 113 shown in FIG. 6 into a group shown in FIG. 8A with record IDs 1131 of "0001" to "0004", and "0006" (hereinafter referred to as the "first group"), a group shown in FIG. 8B with record IDs 1131 of "0005", "0007" to "0010" (hereinafter referred to as the "second group"), and a group shown in FIG. 8C with record IDs 1131 of "0001" to "0004", and "0006" (hereinafter referred to as the "third group").

Returning to FIG. 7, the access procedure acquisition unit 120 then selects one of two groups (hereinafter referred to as a "combination") from the groups obtained by division (S712). In the case of the groups illustrated in FIGS. 8A to 8C, there are three combinations: the first group and the second group, the second group and the third group, and the first group and the third group, and the access procedure acquisition unit 120 selects one of these combinations.

Then, the access procedure acquisition unit 120 determines whether or not one group is in an inclusive relationship with the other group for the combination selected in S712 (S713). If one group is in an inclusive relationship with the other group (S713: YES), the process proceeds to S714, and if one group is not in an inclusive relationship with the other group (S713: NO), the process proceeds to S717.

In the case of the groups illustrated in Figures 8A to 8C, the combination of the first group and the second group is in an inclusive relationship, and the combination of the first group and the third group is in an inclusive relationship with the third group, and the combination of the second group and the third group is in an inclusive relationship with the third group. The method of determining whether one group is in an inclusive relationship with the other group is not necessarily limited, and may be based on, for example, whether the ratio of the number of lines that match between one group and the other group exceeds a preset threshold. In this example, the ratio of matching between the first group and the second group is 100%, the ratio of matching between the first group and the third group is 62.5%, and the ratio of matching between the second group and the third group is 62.5%. For example, if the threshold for determining whether or not there is an inclusive relationship is 80%, only the combination of the first group and the second group is determined to be in an inclusive relationship.

Returning to FIG. 7, in S714, the access procedure acquisition unit 120 reproduces the contents of the access history of the included group (the group with the fewer number of records) and verifies whether an error has occurred (S715). If no error is detected (S715: NO), the process proceeds to S716, and if an error is detected (S715: YES), the process proceeds to S717.

In S716, the access procedure acquisition unit 120 stores the set of records belonging to the included group (the group with the fewer number of records) as candidates for the source of access procedures, and adds 1 to the number of candidates, which is a counter variable provided for each group.

For example, if the groups illustrated in Figures 8A to 8C are all "YES" in S713 and "NO" in S715, then for the combination of the first group and the second group, both are stored as candidates for the extraction source of the access procedure, for the combination of the second group and the third group, the second group is stored, and for the combination of the first group and the third group, the first group is stored as a candidate for the extraction source of the access procedure. In this case, the number of candidates for each group is 2 for the first group, 2 for the second group, and 0 for the third group.

In S717, the access procedure acquisition unit 120 determines whether or not all group combinations have been selected in S712. If all group combinations have been selected in S712 (S717: YES), the process proceeds to S718, and if not all group combinations have been selected (S717: NO), the process returns to S712.

In S718, the access procedure acquisition unit 120 accumulates the number of candidates after eliminating duplicates in the stored candidate groups. For example, in the example of Figures 8A to 8C, the contents of the first and second groups are identical, so the second group is excluded and the number of candidates for the first group is added by 2, resulting in a total of 4.

Then, the access procedure acquisition unit 120 prioritizes the group of candidates whose number of candidates exceeds a preset threshold as the source of the access procedure (S719). For example, in the example of Figures 8A to 8C, if the threshold is set to three times, the number of candidates in the first group is four, which exceeds the threshold, so the access procedure acquisition unit 120 extracts the contents (group of records) of the first group as the source of the access procedure as the access procedure. The access procedure extracted by the access procedure acquisition unit 120 is stored by the storage unit 110 as the access procedure 111.

As described above, the API conversion support device 100 of the second embodiment automatically extracts the access procedure 111 from the access history 113, which is history information generated by using the service of the existing Web application 210, so that the Web API builder 2 does not need to perform operations to reproduce the access procedure of the existing Web application, and the load on the Web API builder 2 can be reduced. Therefore, the existing Web application can be converted into a Web API efficiently. Also, for example, by extracting the access procedure from the access history generated when the existing Web application user 4 uses the service of the existing Web application 210 in a normal usage manner, it is possible to prioritize the conversion into a Web API of, for example, an existing Web application that is frequently used and is expected to have a greater effect from conversion into a Web API.

[Third embodiment]
FIG. 9 shows a schematic configuration of the API support system 1 according to the third embodiment. The API support system 1 of the third embodiment includes an API support device 100, an existing Web server 200, an API adapter 300, and a Web API utilization device 400, as in the API support system 1 of the first embodiment, and further includes a Web API information management device 500. The Web API information management device 500 provides a Web API builder 2 with a search function for Web APIs (existing Web applications). In this embodiment, the Web API information management device 500 is described as being an independent configuration, but all or part of the functions of the Web API information management device 500 may be implemented in another information processing device in the API support system 1. For example, all or part of the functions of the Web API information management device 500 may be implemented in the API support device 100.

The Web API information management device 500 is configured using one or more information processing devices having the configuration shown in FIG.
The application manages information (access procedure 111, API specification 112) relating to a Web API (existing Web application) that has been converted into a Web API by the application program 100, and provides a search function for the above information to other information processing devices communicably connected via a communication network 5.

The API specification setting unit 130 and the information transmission unit 140 of the API implementation support device 100 transmit information (access procedure 111, API specification 112) about the Web API (existing Web application) that has been implemented as a Web API by the API implementation support device 100 to the Web API information management device 500.

As shown in the figure, the Web API information management device 500 has the functions of a storage unit 510, an API management unit 520, and an API search unit 530. These functions are realized by the processor 11 of the information processing device 10 constituting the Web API information management device 500 reading and executing a program stored in the main memory device 12, or by hardware (FPGA, ASIC, AI chip, etc.) provided in the information processing device 10 constituting the Web API information management device 500. The above programs may be stored in the main memory device 12 in advance, or may be stored in the main memory device 12 from a storage device of another device via a communication network or a portable recording medium.

Of the above functions, the storage unit 510 stores information (access procedure group 511, API specification group 512, related information group 513) about the Web API (existing Web application) that has been converted into a Web API by the API conversion support device 100. The above information is managed in association with the identifier of the Web API (existing Web application). The access procedure group 511 includes the access procedure 111 of each Web API (existing Web application). The API specification group 512 includes the API specification 112 of each Web API (existing Web application). The related information group 513 includes various information about each Web API (existing Web application) (explanatory information described below, API adapter URL (URL: Uniform Resource Locator), etc.).

The API management unit 520 receives information (access procedure 111, API specification 112, and the above various information) related to the Web API (existing Web application) sent from the API implementation support device 100. The above information received by the API management unit 520 is stored in the storage unit 510 as an access procedure group 511, an API specification group 512, and a related information group 513, respectively.

The API search unit 530 provides a search function for the information stored in the memory unit 510 to other information processing devices (such as the API support device 100) via the communication network 5. For example, the Web API builder 2 can use the search function via the communication network 5 using a Web browser provided by the API support device 100.

Figure 10 shows an API specification setting screen 3000 that the API specification setting unit 130 of the API support device 100 of the third embodiment presents to the Web API builder 2 (output (display) on the output device 15 (display device)). The Web API builder 2 can register information to be used for searching (access procedure group 511, API specification group 512, related information group 513) in the Web API information management device 500 via the API specification setting screen 3000.

As shown in the figure, the illustrated API specification setting screen 3000 has, in addition to each field of the API specification setting screen 3000 of the first embodiment shown in FIG. 3A, an API adapter URL setting field 351, an explanatory information input field 352, and an information registration button 353. Of these, the URL of the API adapter is set in the API adapter URL setting field 351. Explanation information related to the Web API is set in the explanatory information input field 352. When the information registration button 353 is operated, the information sending unit 140 sends the contents set on the screen to the Web API information management device 500.

Figure 11A is an example of a screen (hereinafter referred to as "Web API information search screen 1100") that the Web API information management device 500 presents (outputs (displays) on the output device 15 (display device)) to the Web API builder 2 when providing a search function. The API search unit 530 of the Web API information management device 500 provides the Web API information search screen 1100 as, for example, a Web page.

The web API information search screen 1100 has a search word setting field 1111, a search execution button 1112, and a search result display field 1113. When the web API builder 2 inputs a search word in the search word setting field 1111 and operates the search execution button 1112, the search word is sent from the web API information management device 500 to the web API information management device 500. When the API search unit 530 of the web API information management device 500 receives the search word, it searches for information corresponding to the search word from the information stored in the memory unit 510 and sends the search results to the API implementation support device 100. When the API implementation support device 100 receives the search results, it displays the received search results in the search result display field 1140 of the web API information search screen 1100.

In the example of FIG. 11A, Web API builder 2 inputs the search word "existing" into search word setting field 1111, and information containing the word "existing" in the URL of an existing Web application is displayed in search result display field 1140 as a search result. The content of each record (entry) in search result display field 1140 corresponds to one Web API (existing Web application). Each record has the following items: existing Web application URL 1141, API adapter URL 1142, and description 1143.

Each record in the search result display column 1140 is provided with a display button 1161 for checking the access procedure to be reproduced by the API adapter 300. When the Web API builder 2 operates the display button 1161, information about the Web API (existing Web application) is displayed.

Figure 11B shows an example of the display of the above information (hereinafter referred to as "access procedure display screen 1150"). The illustrated access procedure display screen 1150 is displayed by operating the display button 1161 in the second row of the search result display field 1140 in Figure 11A. As shown in the figure, the access procedure display screen 1150 displays the access procedures of the existing Web application (chronologically ordered records (entries) having the items of user ID 1151, operation 1152, and operation target 1153).

By referring to information such as that shown in Figures 11A and 11B, the Web API builder 2 can, for example, check whether a Web API that is the same as or similar to the one he or she wants to build already exists, and if so, can use this to efficiently perform the migration work to the Web API. In addition, for example, the Web API builder 2 can search for information that can be used as a reference for the Web API that he or she is about to build, and can efficiently perform the migration to the Web API. In this way, according to the configuration of the third embodiment, the information accumulated by the migration of the Web API can be effectively utilized to increase the efficiency of the migration work to the Web API.

Although the embodiment of the present invention has been described above, it goes without saying that the present invention is not limited to the above embodiment and can be modified in various ways without departing from the gist of the invention. For example, the above embodiment has been described in detail to clearly explain the present invention, and is not necessarily limited to having all of the configurations described. In addition, it is possible to add, delete, or replace part of the configuration of the above embodiment with other configurations.

In addition, the above-mentioned configurations, functional units, processing units, processing means, etc. may be realized in part or in whole by hardware, for example, by designing them as integrated circuits. In addition, the above-mentioned configurations, functions, etc. may be realized in software by a processor interpreting and executing a program that realizes each function. Information such as the program, table, file, etc. that realizes each function can be stored in a storage device such as a memory, a hard disk, or an SSD (Solid State Drive),
It can be placed on a recording medium such as an IC card, an SD card, or a DVD.

Furthermore, the layout of the various functional units, various processing units, and various databases of each information processing device described above is merely an example. The layout of the various functional units, various processing units, and various databases can be changed to an optimal layout in terms of the performance, processing efficiency, communication efficiency, etc. of the hardware and software equipped in these devices.

In addition, the configuration (schema, etc.) of the database that stores the various types of data described above can be flexibly changed from the perspective of efficient use of resources, improved processing efficiency, improved access efficiency, improved search efficiency, etc.

1 API implementation support system, 2 Web API builder, 3 Web API user, 4 Existing Web application user, 5 Communication network, 100 API implementation support device, 110 Memory unit, 111 Access procedure, 112 API specification, 113 Access history, 120 Access procedure acquisition unit, 130 API specification setting unit, 140 Information transmission unit, 145 Access history reception unit, 200 Existing Web server, 210 Existing Web application, 220 Access history transmission unit, 300 API adapter, 310 Information reception unit, 320 Memory unit, 321 Access procedure, 322 API specification, 330 Access procedure reproduction unit, 340 Web API provision unit, 400 Web API utilization device, 410 Web API utilization application, 500 Web API information management device, 510 Memory unit, 511 Access procedure group, 512 API specification group, 513 related information group, 520 API management unit, 530 API search unit, S700
Access procedure extraction process, 3000 API specification setting screen

Claims (10)

The information processing device includes a processor and a storage device.
an access procedure acquisition unit that acquires, as an access procedure, a series of operations performed via a web browser on a web application to be converted into an API;
an API specification setting unit that generates API specifications by presenting the acquired contents of the access procedure to a user and receiving settings of API specifications required for the API conversion from the user;
an access history acquisition unit that acquires an access history, which is a history of operations performed on the Web application;
Equipped with
the access procedure acquisition unit acquires the series of operations included in the access history as the access procedure;
the access procedure acquisition unit classifies the access history into a plurality of groups based on at least one of whether the operations are performed by a common subject and the continuity of the intervals between the dates and times when the operations are performed, identifies an inclusion relationship between the plurality of groups, selects a group that is included as a candidate from which the access procedure is extracted, and acquires the series of operations included in the selected candidate group as the access procedure.
API support system. 2. The API implementation support system according to claim 1 ,
the access procedure acquisition unit preferentially selects a group having a high appearance frequency from among the candidate groups as a source from which the access procedure is to be extracted, and acquires the series of operations included in the selected candidate group as the access procedure.
API support system. The information processing device includes a processor and a storage device.
an access procedure acquisition unit that acquires, as an access procedure, a series of operations performed via a web browser on a web application to be converted into an API;
an API specification setting unit that generates API specifications by presenting the acquired contents of the access procedure to a user and receiving settings of API specifications required for the API conversion from the user;
an API management unit that manages information related to the access procedure and the API specification in association with an identifier of an API realized by the access procedure and the API specification;
an API search unit that receives a keyword for searching the information, searches the information using the received keyword, and outputs a result of the search;
Equipped with
API support system. 4. The API implementation support system according to claim 3 ,
the API management unit manages related information, which is information relating to the access procedure and the API specification, as the information to be searched together with the access procedure and the API specification;
The API search unit receives a keyword for searching the information, searches the information using the received keyword, and outputs a result of the search.
API support system. The API implementation support system according to claim 4 ,
a user interface for receiving the related information;
API support system. An information processing device having a processor and a storage device,
acquiring, as an access procedure, a series of operations performed via a web browser on a web application to be converted into an API;
generating an API specification by presenting the acquired contents of the access procedure to a user and receiving from the user settings of the API specification required for the API implementation;
acquiring an access history which is a history of operations performed on the Web application;
acquiring the series of operations included in the access history as the access procedure;
a step of classifying the access history into a plurality of groups based on at least one of the common subject of the operations and the continuity of the intervals between the dates and times when the operations were performed, identifying an inclusion relationship between the plurality of groups, selecting the included group as a candidate from which the access procedure is to be extracted, and acquiring the series of operations included in the selected candidate group as the access procedure;
The API support method executes the above. The API implementation support method according to claim 6 ,
the information processing device preferentially selecting a group having a high appearance frequency from among the candidate groups as a source from which the access procedure is to be extracted, and acquiring the series of operations included in the selected candidate group as the access procedure;
The API implementation support method further executes the above. An information processing device having a processor and a storage device,
acquiring, as an access procedure, a series of operations performed via a web browser on a web application to be converted into an API;
generating an API specification by presenting the acquired contents of the access procedure to a user and receiving from the user settings of the API specification required for the API implementation;
managing information relating to the access procedure and the API specification in association with an identifier of an API realized by the access procedure and the API specification;
receiving a keyword for searching the information, searching the information using the received keyword, and outputting a result of the search;
The API support method executes the above. The API implementation support method according to claim 8 ,
The information processing device,
managing related information, which is information relating to the access procedure and the API specification, as the information to be searched together with the access procedure and the API specification;
receiving a keyword for searching the information, searching the information using the received keyword, and outputting a result of the search;
The API implementation support method further executes the above. The API implementation support method according to claim 9 ,
a step of the information processing device providing a user interface for receiving the related information;
The API implementation support method further executes the above.

Images