JP2017041158A - Api conversion table generator, api conversion table generation method, and api conversion table generation program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To automatically generate a conversion table for converting an API (application program interface) into the API conforming to another API provisions.SOLUTION: An API conversion table generator 1 generates an API conversion table 221 which absorbs a difference between an original API and a common API, which comprises: a mapping section 122 that carries out a series of mapping processing to make one-to-one pairs of data or groups having high similarity between a common API and an original API; and a conversion table creation section 123 that creates the API conversion table 221 on the basis of the mapping by the mapping section 122.SELECTED DRAWING: Figure 2

Description

  The present invention relates to an API conversion table generation device, an API conversion table generation method, and an API conversion table generation program that generate a conversion table for an API (Application Program Interface) request.

  With the recent increase in network speed and the spread of web browsers, APIs that provide predetermined processing via the Internet have become widespread. This API is a rule that defines the procedure and data format for calling and using programs and management data on a server via the Internet from other servers and terminals. It is called by imitating an API that is a convention for calling and using.

  Developers can easily develop applications for end users by using APIs. In addition, API providers can appeal their services and content to end users, etc., using applications that utilize this API. For example, a communication carrier can promote development of an application for an end user by using a network function or an operation function as an API, and can appeal its communication service to an end user or the like.

  In recent years, devices such as smartphones have diversified, and the market has become global, making it easier for businesses to enter new niche areas. Under such circumstances, it is important to provide APIs in a form that can secure profits. In order to realize these services and secure profits, it is desirable that APIs (mashups) be easy between operators. To enable API linkage, it is desirable to define API technical standards and unify them into standard APIs that conform to them.

  For example, Non-Patent Document 1 describes this standard API model. TM (TeleManagement) FORUM, the publisher of this Non-Patent Document 1, is working on the examination of industry standards, the promotion of commercialization based on that, and the activation of the industry in order to realize network management of interoperable information communication systems. It is a non-profit industry organization established for the purpose, and is examining a standard API for providing services across multiple operators.

FIG. 13A shows an example of a GET request in the REST (REpresentational State Transfer) format adopted by the standard API of TMF (TeleManagement FORUM), and FIG. 13B shows an example of a response.
As described above, in the REST format API, a processing request is transmitted to the system by “GET” which is an HTTP (Hypertext Transfer Protocol) method, and a response is received by an HTTP response. In the REST format, processing requests can be transmitted by using five HTTP methods “GET”, “POST”, “PUT”, “PATCH”, and “DELETE”.

TeleManagement FORUM, “Frameworx Specification Product Ordering API REST Specification”, Release 14.5.0, November 2014

As described above, when cooperation between providers is performed, for example, it is desirable to unify to a common API (hereinafter referred to as a common API) conforming to the TMF standard. On the other hand, in existing systems, APIs are also developed independently due to the uniqueness of the environment and services, and a difference from the common API occurs.
Therefore, it is possible to absorb the difference between the common API and the original API, create a conversion table that converts the original API according to the common API rules, and execute the same processing as the common API without changing the original API. It is desirable to do. However, creating such a conversion table requires a lot of man-hours and costs.

  An object of the present invention is to solve the above-described problems and automatically generate a conversion table for converting one API into an API that conforms to another API specification.

  In order to solve the above-mentioned problem, the invention according to claim 1 is an API conversion table generation device that generates an API conversion table that absorbs a difference between a first API and a second API, A mapping unit that maps data or groups having high similarity between the second APIs on a one-to-one basis, and a conversion table creation unit that creates the API conversion table based on the mapping by the mapping unit. An API conversion table generation device characterized by

  By doing so, it is possible to automatically generate a conversion table for converting one API into an API that conforms to other API specifications.

  The API conversion table generation device according to claim 1, further comprising an API tree creation unit that creates a tree structure of the resource model of the first and second APIs. It was.

  By doing so, it is possible to perform mapping of the resource models of the first and second APIs at high speed.

  According to a third aspect of the present invention, in the API conversion table generating device according to the second aspect, the mapping unit performs mapping based on the similarity of the data in the lowest layer of the tree structure.

  By doing so, it is possible to easily map the resource models of the first and second APIs.

  The invention according to claim 4 is characterized in that the mapping unit calculates the similarity by comparing the name of the lowest layer data of the tree structure and / or the description of the data. The described API conversion table generation device was used.

  By doing in this way, the resource model of the 1st and 2nd API can be mapped irrespective of manual work.

  In the invention according to claim 5, when the data of the first API is mapped to a plurality of data of the second API, the mapping unit sequentially expands a group including each data to an upper node. 4. The API conversion table generation device according to claim 3, wherein groups are compared between the first API and the second API, and groups having a high degree of similarity are mapped one-to-one. 5. It was.

  By doing so, it is possible to perform mapping of the resource models of the first and second APIs without error.

  In the invention according to claim 6, if the first API and the second API match in a group unit, the conversion table creation unit creates the API conversion table in a group unit. The API conversion table generating device according to claim 1 is provided.

  By doing so, it is possible to convert the API easily and at high speed by reducing the number of mapping entries included in the API conversion table.

  The invention according to claim 7 is an API conversion table generation method executed by an API conversion table generation device that generates an API conversion table that absorbs a difference between the first API and the second API, the API conversion table A table generating device mapping data or groups having a high degree of similarity between the first and second APIs on a one-to-one basis, and the API conversion table based on a mapping result of the data or the groups And a step of creating an API conversion table generation method.

  By doing this, it is possible to automatically generate a conversion table for converting one API into an API that conforms to other API specifications.

  In the invention according to claim 8, a procedure for causing a computer to map data or groups having a high similarity between the first API and the second API on a one-to-one basis, and to the mapping result of the data or the group Based on this, an API conversion table generation program for executing an API conversion table that absorbs the difference between the first API and the second API is provided.

  By doing this, it is possible to automatically generate a conversion table for converting one API into an API that conforms to other API specifications.

  According to the present invention, it is possible to automatically generate a conversion table for converting one API into an API conforming to another API rule.

1 is a system configuration diagram including an API conversion apparatus and an API conversion table generation apparatus in the present embodiment. It is a schematic block diagram of an API conversion device and an API conversion table generation device. It is a flowchart which shows the process of an API structure comparison part. It is a figure which shows the example which expressed the UML model by the tree structure. It is a figure explaining operation | movement of an API tree preparation part. It is explanatory drawing of the operation example (the 1) of a mapping part. It is explanatory drawing of the operation example (the 2) of a mapping part. It is explanatory drawing of the operation example (the 3) of a mapping part. It is explanatory drawing of the operation example (the 4) of a mapping part. It is explanatory drawing of the operation example of a conversion table preparation part. It is explanatory drawing of the other operation example of a conversion table preparation part. It is explanatory drawing of the other operation example of a conversion table preparation part. It is a figure which shows the example of a REST GET request and a response.

Next, modes for carrying out the present invention (referred to as “embodiments”) will be described in detail with reference to the drawings as appropriate.
FIG. 1 is a system configuration diagram including an API conversion device 2 and an API conversion table generation device 1 in the present embodiment.
The system shown in FIG. 1 enables communication between a system 41 operated by the service provider 4 and a new system 31 and an existing system 32 operated by the network provider 3. The new system 31 includes an orchestrator 33. Here, the orchestrator 33 is a mechanism that automates the construction and operation of a system by defining resource allocation, settings, dependencies, and the like on the cloud. The orchestrator 33 can build a system on the cloud all at once, and can also prepare many consistent environments.

  The existing system 32 communicates with a unique API (first API), and the new system 31 communicates with a common API (second API). Communication data of the common API of the new system 31 is transmitted as it is to the system 41 of the service provider 4 via the API aggregation 5. That is, the API aggregation 5 relays the communication data of the common API without converting it.

  On the other hand, the communication data of the unique API of the existing system 32 is converted into a common API via the API aggregation 5 and transmitted (relayed) to the system 41 of the service provider 4. Conversion between the original API and the common API is performed by the API conversion device 2.

  The API conversion device 2 receives a table used for this conversion from the API conversion table generation device 1. Details of the API conversion device 2 and the API conversion table generation device 1 will be described below with reference to FIG.

FIG. 2 is a schematic block diagram of the API conversion device 2 and the API conversion table generation device 1.
The API conversion device 2 converts the original API and the common API to each other. The API conversion device 2 includes an API input unit 21 that receives API requests and responses, an API processing unit 22 that processes API inputs, and an API output unit 23 that outputs API requests and responses. . The API processing unit 22 includes an API conversion table 221 that stores conversion information between a unique API and a common API, an API conversion unit 222 that converts APIs, and an API mashup that links a plurality of APIs into a new API. The unit 223 is configured. The API conversion device 2 is a computer having a CPU (Central Processing Unit), a ROM (Read Only Memory), a RAM (Random Access Memory), and the like. To embody.

  When an API is input to the API input unit 21 by the API conversion device 2, this API is appropriately converted and mashed up by the API processing unit 22 and output by the API output unit 23.

  The API conversion table generation device 1 generates an API conversion table 221 that stores conversion information between the unique API and the common API. The API conversion table generating device 1 includes an API structure receiving unit 11, an API structure comparing unit 12, a conversion table draft presenting unit 13, a conversion table correction input unit 14, a conversion table output unit 15, a common API information holding unit 16, dictionary data. A holding unit 17, an external information acquisition unit 18, and a dictionary data correction unit 19 are included. The API structure comparison unit 12 includes an API tree creation unit 121, a mapping unit 122, and a conversion table creation unit 123. The API conversion table generation apparatus 1 is a computer having a CPU, a ROM, a RAM, and the like, and implements the above-described units by executing an API conversion table generation program (not shown).

  The API structure receiving unit 11 receives information indicating the API structure and passes it to the API structure comparing unit 12. The API tree creation unit 121 of the API structure comparison unit 12 creates this API as a tree structure. The mapping unit 122 matches and maps the common API and the unique API. The conversion table creation unit 123 creates an API conversion table 221 from the mapping result. The processing of the API structure comparison unit 12 will be described later.

  The API conversion table 221 is presented to the user by the conversion table draft presenting unit 13, receives the user's correction input by the conversion table correction input unit 14, and is output to the API conversion device 2 by the conversion table output unit 15.

  The common API information holding unit 16 holds common API specification information. The dictionary data holding unit 17 holds dictionary data for mapping by mapping the common API and the unique API. The external information acquisition unit 18 acquires external information, for example, specification information of a unique API or synonym information on a network. The dictionary data correction unit 19 corrects the dictionary data stored in the dictionary data holding unit 17. The user can rewrite the dictionary data via the dictionary data correction unit 19.

  In this embodiment, the API conversion table generation device 1 automatically extracts the difference between the unique API and the common API of the existing system 32 and generates the API conversion table 221. The API conversion device 2 performs API processing based on the API conversion table 221.

FIG. 3 is a flowchart showing processing of the API structure comparison unit 12.
When the unique API of the existing system 32 (see FIG. 1) and the resource model and data structure of the common API are input, the process of FIG. 3 starts. Here, the resource model and data structure of the original API and the common API may be prepared in advance.

  First, the API structure comparison unit 12 uses the API tree creation unit 121 to create a resource model tree structure of the unique API and the common API (step S10). Next, the API tree creation unit 121 uses the mapping unit 122 to match the lowest layer nodes of the resource model having the tree structure of the unique API and the common API, map the data name (step S11), and further delete the unique node. (Step S12). At the time of this mapping, the API tree creation unit 121 calculates the similarity between both APIs from the data names constituting the resource model of the unique API and the common API, and performs one-to-one association. At this point, the correspondence between the unique API and the common API may be one-to-many.

Next, the mapping unit 122 expands the group to the next higher node for each of the unique API and the common API (step S13), and maps these groups by comparing each other (step S14).
Here, the mapping unit 122 determines whether or not there is a one-to-many correspondence (step S15). If there is no one-to-many correspondence, the conversion table creation unit 123 creates the API conversion table 221 from the mapping result (step S17), and ends the processing of FIG.
If there is a one-to-many correspondence in the determination in step S15, the mapping unit 122 determines whether or not the group is expanded to the highest node (step S16), and expands the group to the highest node. If not, the process returns to step S13 to further expand the group. Thereby, it can be made one-to-one correspondence as much as possible.
If the group has been expanded to the highest node, the conversion table creation unit 123 creates the API conversion table 221 from the mapping result (step S17), and ends the processing of FIG.

  When communication via API is performed from the existing system 32 to the common API compliant system 41 or enabler, the API conversion is performed based on the API conversion table 221 (see FIG. 2), so that the existing system 32 can be handled. Without adding, it is possible to access the system 41 and the enabler implemented with the common API.

In the operation example described below, it is assumed that REST is adopted for both the original API and the common API of the existing system 32. Further, it is assumed that the common API has a resource name and a data structure defined according to the TMF standard API model, and the resource name and the data structure use the names described in TMF as they are.
Although TMF defines a model, the implementation is left to each business operator, and a specific name may be used even for an API that complies with the TMF rules.

FIG. 4 is a diagram illustrating an example in which the UML model is expressed by a tree structure.
The original API and common API of the existing system 32 use the same REST format protocol, and the resource model and data structure can be grasped in advance. FIG. 4 illustrates the tree structure of the resource model of the unique API or common API created by the API tree creation unit 121. In each tree structure, a rectangle is a node indicating a resource name of the tree structure. A rectangle with rounded corners is a node indicating data.

FIG. 5 is a diagram for explaining the operation (part 1) of the API tree creation unit 121. FIG. 5 shows a state immediately after step S10 in the flowchart of FIG.
The unique API specification 62 includes “API10” having a tree structure. The common API specification 61 includes “API1”, “API2”, “API3”, and “API4” in a tree structure.
The API tree creation unit 121 compares and maps the nodes (data) in the lowest layer of the unique API specification 62 and the common API specification 61. Nodes that cannot be mapped are regarded as unique data. Since the data item name of the existing system 32 may be unique, similarity calculation is required for matching, which will be described with reference to FIG.

In the tree structure of the resource model, it is possible to narrow down the mapping range by performing mapping from an upper node, but in this case, mapping may not be possible due to narrowing down.
For example, if “service order” and “ProductOrder” can be regarded as matching, the search range can be narrowed down. However, since customer information is included in “Customer” in the common API specification 61, only the search for “ProductOrder” is possible. Is not sufficient and cannot be mapped. Therefore, in this embodiment, mapping is performed from the lowest layer node (data) of the common API specification 61 and the unique API specification 62. In the mapping from the top, there is also a method of searching once and then expanding the range to other APIs if it is not found.

FIG. 6 is an explanatory diagram of an operation example (part 1) of the mapping unit 122.
The mapping unit 122 calculates the similarity using the data name and “other information”, and matches the API data name.
In the similarity calculation, the mapping unit 122 calculates, for example, the similarity between the data name of the common API specification 61 and the data name of the unique API specification 62 and multiplies the first coefficient. The mapping unit 122 further calculates the similarity between the “other information” of the common API specification 61 and the “other information” of the unique API specification 62 and multiplies the second coefficient, and the data name of the common API specification 61 and the unique API The degree of similarity between “other information” of the specification 62 is calculated and multiplied by the third coefficient, the degree of similarity between “other information” of the common API specification 61 and the data name of the unique API specification 62 is calculated, and the fourth coefficient Multiply Finally, the mapping unit 122 calculates the sum of the multiplication results of these four terms and sets this as the similarity between the original API and the common API at the corresponding node.
In the data name of the unique API specification 62 of the existing system 32, the Japanese description defined in the interface specification is used. In the data name of the common API specification 61, in addition to the English description of the data name, a synonym list is created from the data name, and the Japanese meaning of the data name is searched to reinforce the meaning of the data name. In addition, accuracy can be improved by performing similarity calculation using the data name and other information. Since Japanese is not divided, the "other information" part written in Japanese is decomposed into word units and compared by morphological analysis or the like.

  In the similarity calculation, there may be a case where the mapping is not uniquely determined. If mapping is not decided, temporarily hold and then map at the subsequent resource level. Moreover, the accuracy of similarity calculation can be improved by using the information described in the interface specification as supplementary information.

  In the example shown in FIG. 6, the data in the first row of the unique API specification 62 and the data in the first and second rows of the common API specification 61 are compared. The word “customer” matches the data name in the first line of the unique API specification 62 and “other information” in the first line of the common API specification 61. Furthermore, “No” of the data name on the first line of the unique API specification 62 and “id” of the data name on the first line of the common API specification 61 have the same purpose. Further, “customer-specific” described in “other information” on the first line of the original API specification 62 and “code used for identification” described in “other information” on the first line of the common API specification 61. And the purpose matches. Therefore, the similarity between the data in the first row of the unique API specification 62 and the data in the first row of the common API specification 61 is high.

  The word “customer” matches the data name in the first line of the unique API specification 62 and “other information” in the second line of the common API specification 61. However, since there is no other match, the similarity between the data in the first row of the unique API specification 62 and the data in the second row of the common API specification 61 is relatively low.

  The similarity calculation is searched using a dictionary given in advance. In addition to using existing dictionaries, technical terms and technical abbreviations are considered to be included, so it is recommended to add supplementary information. Specifically, the additional supplementary information is an abbreviation such as “SO”, for example, and may be acquired from the outside such as the Internet or manually input.

FIG. 7 is an explanatory diagram of an operation example (part 2) of the mapping unit 122. FIG. 7 shows a state immediately after step S11 in the flowchart of FIG.
As shown in FIG. 7, the “API10” data 321 and 322 of the unique API specification 62 can be mapped one-to-one with the “API3” data 311 and 312 of the common API specification 61.
The “API10” data 323 of the unique API specification 62 can be mapped to the “API1” data 313 of the common API specification 61 on a one-to-one basis. The “API10” data 324 of the unique API specification 62 can be mapped to the “API4” data 314 of the common API specification 61 on a one-to-one basis.

The “API10” data 325 of the unique API specification 62 is mapped one-to-many with the “API1” data 317 and the “API2” data 315 of the common API specification 61. The “API10” data 326 of the unique API specification 62 is mapped one-to-many to the “API1” data 318 and the “API2” data 316 of the common API specification 61.
Note that a rectangle indicated by a broken line indicates a node (data) that has not been mapped. This is called an original node.

FIG. 8 is an explanatory diagram of an operation example (part 3) of the mapping unit 122. FIG. 8 shows a state immediately after step S13 in the flowchart of FIG.
The mapping unit 122 performs grouping by considering the nodes from the lowest layer up one level as one group, with the unique node excluded. Compare groups with each other.
Here, the mapping unit 122 groups the nodes up to one of the data 311 and 312 of the “API3” of the common API specification 61 to form a group G1b. The nodes up to one point above the data 315 and 316 of “API2” of the common API specification 61 are grouped into a group G2b.

  Further, the mapping unit 122 groups the nodes up to one data 313 of “API1” of the common API specification 61 into a group G3b. The nodes up to one level above the data 317 and 318 of “API1” of the common API specification 61 are grouped into a group G4b. Next, the mapping unit 122 groups the nodes up to one point above the data 314 of “API4” of the common API specification 61 to form a group G5b.

FIG. 9 is an explanatory diagram of an operation example (part 4) of the mapping unit 122. FIG. 9 shows a state immediately after step S15 in the flowchart of FIG.
When the nodes included in the group match each other, the mapping unit 122 performs mapping in units of groups. For example, the mapping unit 122 maps the “API10” group G1a of the unique API specification 62 and the “API3” group G1b of the common API specification 61. Further, the “API10” group G2a of the unique API specification 62 and the “API2” group G2b of the common API specification 61 are mapped. Here, the group G4b of “API1” of the common API specification 61 is not mapped because it has been found that it is a data group different from the group G2a of “API10” of the unique API specification 62 as a result of expanding the group.
In this way, the mapping unit 122 repeats group expansion until the groups are mapped one-on-one. That is, it repeats to the top node of the tree structure.

10A and 10B are explanatory diagrams of an operation example of the conversion table creation unit 123. FIG. FIGS. 10A and 10B show the process of step S16 in the flowchart of FIG.
FIG. 10A is a diagram illustrating the correspondence between the mapping result and each node name.
The group G1a includes a node “A” of “API10” of the unique API specification 62 and data 321 and 322 belonging thereto. The group G1b mapped to this group G1a includes the node “API3-a” of “API3” of the common API specification 61 and the data 321 and 322 belonging thereto.

The data 323 further belongs to the node “a” belonging to the node “B” of “API10” of the unique API specification 62, and the name is “data1”. Data 313 mapped to this data 323 is data subordinate to the node “API1-a” of “API1” of the common API specification 61, and the name is “d1”.
The data 324 further belongs to the node “a” belonging to the node “B” of “API10” of the unique API specification 62, and the name is “data2”. The data 314 mapped to the data 324 is data subordinate to the node “API4-a” of “API4” of the common API specification 61, and the name is “d2”.

  The group G2a includes a node “b” belonging to the node “B” of “API10” of the unique API specification 62, and data 325 and 326. The group G2b mapped to the group G2a includes a node “API2-b” of “API2” of the common API specification 61 and data 315 and 316 belonging to the node “API2-b”.

FIG. 10B shows an example of the created API conversion table 221.
“/ API10 / A” of the original API specification 62 is converted to “/ API3 / API3-a” of the common API specification 61. This is created by the mapping result between the group G1a and the group G1b. Thus, by creating the API conversion table 221 from the grouped mapping result, the number of entries in the API conversion table 221 can be reduced.
“/ API10 / B / b” of the original API specification 62 is converted to “/ API2 / API2-b” of the common API specification 61. This is created by the mapping result of the group G2a and the group G2b.

“/ API10 / B / a / data1” of the original API specification 62 is converted to “/ API1 / API1-a / d1” of the common API specification 61. This is created by the mapping result between the data 323 and the data 313.
“/ API10 / B / a / data2” of the original API specification 62 is converted to “/ API4 / API4-a / d2” of the common API specification 61. This is created by the mapping result between the data 324 and the data 314.
Note that grouping may be performed in units of data. Thereby, a mapping result can be obtained in a short time.

FIGS. 11A to 11C are explanatory diagrams of another operation example of the conversion table creation unit 123. FIG.
The API conversion table 221 is created based on the mapping pattern as follows.
FIG. 11A shows a pattern in which group data or individual data matches.
At this time, the conversion table creation unit 123 creates the API conversion table 221 by enclosing the group name of “customer information” in the unique API specification 62 and the group name of “Customer” in the common API specification 61. “Customer number” is mapped to “id”, and “name” is mapped to “name”.

FIG. 11B shows a pattern in which group data or individual data matches.
At this time, the conversion table creation unit 123 creates an API conversion table 221 by mapping “/ Tracquet / user name” of the unique API specification 62 and “/ Customer / name” of the common API specification 61. Note that “Torachiquet” described here is an abbreviation of trouble ticket.

FIG. 11C shows a pattern in which the data granularity is different and the data can be divided.
At this time, the conversion table creation unit 123 performs mapping based on a rule for bundling requests and responses and a rule for division. For example, when “/ customer information / last name” and “/ customer information / first name” of the unique API specification 62 are bundled, they can be mapped to “/ Customer / name” of the common API specification 61.

FIG. 12 is an explanatory diagram of another operation example of the conversion table creation unit 123.
Here, a description will be given of patterns that have different data granularities and that make sense only when a plurality of data is bundled. For example, when the data A, B, and C of the original API specification 62 are prepared and the same meaning as the data a, b, c, and d of the common API specification 61 is made, buffered temporarily and divided requests Convert when all the responses to are complete.
Thus, patterns having different data granularities may be converted after obtaining all responses to the divided requests using the function of the API mashup unit 223. Further, when there is a shortage of requests or responses, means such as returning dummy data (including null information) or requesting an additional request together with an error code is possible.

  Note that data items that cannot be automatically mapped may be listed by the conversion table draft presenting unit 13 (see FIG. 2) and then notified to the administrator (human). Thereby, it is possible to favorably support generation of an appropriate API conversion table by the administrator.

(Modification)
The present invention is not limited to the above-described embodiment, and can be modified without departing from the spirit of the present invention. For example, there are the following (a) to (c).
(A) The API conversion direction is not limited. In addition to converting the original API into the common API, the common API may be converted into the original API.
(B) The API conversion table generation device 1 may be configured separately from the API conversion device 2, and may be implemented as an API conversion table generation means inside the API conversion device 2, and is not limited.
(C) The API format is not limited to REST, and may be another protocol format such as SOAP (Simple Object Access Protocol).

DESCRIPTION OF SYMBOLS 1 API conversion table production | generation apparatus 11 API structure reception part 12 API structure comparison part 121 API tree creation part 122 Mapping part 123 Conversion table creation part 16 Common API information holding part 17 Dictionary data holding part 18 External information acquisition part 2 API conversion apparatus 21 API input unit 22 API processing unit 221 API conversion table 222 API conversion unit 223 API mashup unit 23 API output unit 3 Network operator 31 New system 32 Existing system 33 Orchestrator 4 Service provider 41 System 5 API aggregation

Claims (8)

An API conversion table generation device that generates an API conversion table that absorbs a difference between a first API and a second API,
A mapping unit for mapping data or groups having a high degree of similarity between the first and second APIs on a one-to-one basis;
Based on the mapping by the mapping unit, a conversion table creating unit that creates the API conversion table;
An API conversion table generating device comprising: An API tree creation unit for creating a tree structure of the resource model of the first and second APIs;
The API conversion table generation device according to claim 1, wherein The mapping unit performs mapping according to the similarity of data in the lowest layer of the tree structure.
The API conversion table generating apparatus according to claim 2, wherein The mapping unit calculates the similarity by comparing the name of the lowermost data of the tree structure or / and the description of the data,
The API conversion table generation device according to claim 3, wherein When the data of the first API is mapped to a plurality of data of the second API, the mapping unit sequentially expands a group including each data to an upper node and the first API and the first API Compare the groups with the API of 2 and map the groups with high similarity one-to-one.
The API conversion table generation device according to claim 3, wherein The conversion table creation unit creates the API conversion table in a group unit when the first API and the second API match in a group unit.
The API conversion table generation device according to claim 1, wherein An API conversion table generation method executed by an API conversion table generation device that generates an API conversion table that absorbs a difference between a first API and a second API,
The API conversion table generating device mapping data or groups having a high degree of similarity between the first and second APIs on a one-to-one basis;
Creating the API conversion table based on the mapping result of the data or the group;
A method for generating an API conversion table, comprising: On the computer,
A procedure for mapping data or groups having a high similarity between the first API and the second API on a one-to-one basis;
A procedure for creating an API conversion table that absorbs a difference between the first API and the second API based on the mapping result of the data or the group;
API conversion table generation program to execute.

Images