JP2017054411A - API conversion adapter, API conversion system, and API conversion program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To establish a conversion processing technique capable of generally coping with various types of protocol as a method of making an existing system become REST API, and provide an API conversion adapter, an API conversion system, and an API conversion program using the technique.SOLUTION: As a REST API conversion processing technique capable of generally coping with various types of protocol, an API conversion adapter 30 is an API conversion adapter for making an existing system 40 become API, and comprises: a database (storage part 36) which previously stores packet sending-receiving sequence with the existing system 40; an extraction part 31 which extracts parameters in a received packet; a replacement part 32 which replaces the parameters in the packet stored in the database into parameters extracted by the extraction part 31; and a client part 33 which executes sending-receiving of the packet with the existing system 40 by using the packet replaced by the replacement part 32.SELECTED DRAWING: Figure 4

Description

  The present invention relates to an API conversion adapter, an API conversion system, and an API conversion program for converting an existing system into an API.

  In the market, IT service development / provision forms and devices are changing, and a trend to easily develop new services in a short period of time by utilizing published API (Application Programming Interface) is being established. The number of public APIs has increased significantly in recent years, and in particular, the number of APIs for design methods compliant with REST (Representational State Transfer), which is a Web application design style, is remarkable.

  REST is a software design format for constructing services mainly on the Web, and is recently known as a method suitable for linking a plurality of services. Specifically, as shown in FIG. 16, when the application A designates a resource identifier (URI) and a request type (GET / POST / PUT / DELETE etc.) and accesses with HTTP, the application B, which is the access destination, is in XML format. It refers to a system and a call interface in which resource data described in the JSON format is sent. REST does not necessarily require complicated prior information as compared with SOAP or the like, and may be used more easily, and it is estimated that there are many users.

Japanese Patent No. 5089621 JP 2009-009455 A Japanese Patent Laid-Open No. 2007-026150 JP 2005-512210 A US Patent Application Publication No. 2007/0050446

  In order to convert the functions of the existing system into the REST API, it is necessary to unify various protocols adopted in the existing system into the REST-compliant HTTP and maintain the API (see FIG. 17). Conventionally, a technique for creating an individual protocol / data conversion processing program or the like for each system is required, and the creation of the program or the like requires a great deal of cost.

  In order to improve the above-described problems, the present invention aims to establish a conversion processing technique that can be used for various protocols in general as a REST API method for an existing system. An API conversion adapter and an API conversion system using this technique are provided. And an API conversion program.

  In order to achieve the above object, the invention according to the first aspect is an API conversion adapter for converting an existing system into an API, and has received a database storing a packet transmission / reception sequence with the existing system in advance. An extraction unit for extracting a parameter in the packet; a replacement unit for replacing the parameter in the packet stored in the database with the parameter extracted by the extraction unit; and the packet replaced by the replacement unit, The gist is to include an existing system and a client unit that performs transmission and reception of packets.

  The gist of the invention according to the second aspect is that it is deployed between the existing system and the API gateway in the invention according to the first aspect.

  The invention according to the third aspect is characterized in that, in the invention according to the second aspect, the API gateway performs request reception and response return with REST, and performs transmission and reception with the existing system using the existing protocol. .

  An invention according to a fourth aspect is an API conversion system for converting an existing system into an API, the API gateway providing an API for controlling the existing system from an application side on an external network And an API conversion adapter according to any one of the first to third aspects.

  The invention according to the fifth aspect is an API conversion program, characterized by causing a computer to function as each functional unit according to any one of the first to third aspects.

  According to the present invention, as a REST API conversion method for an existing system, a conversion processing technology that can be used for various protocols can be used, and an API conversion adapter, an API conversion system, and an API conversion program using this technology can be used. Provision is possible.

It is a figure for demonstrating the API conversion adapter function with respect to some protocols in embodiment of this invention. It is a figure which shows three realization methods which make existing system REST API in embodiment of this invention, (a) Realization method 1, (b) Realization method 2, (c) Realization method 3. It is a figure of the example of application of the API conversion adapter for converting the existing system into REST API in embodiment of this invention, (a) Existing form, (b) Embodiment of this invention. It is a functional block diagram of an API conversion adapter in an embodiment of the present invention. It is a block diagram of DB which the storage part in embodiment of this invention stores. It is a figure which shows a mode that a some application uses the existing system using the API conversion adapter in embodiment of this invention. It is a figure which shows the specific example of a request in the case of implementing API conversion using the API conversion adapter in embodiment of this invention, and a response. It is a flowchart which shows the operation example in the case of implementing API conversion using the API conversion adapter in embodiment of this invention. It is a figure for demonstrating a mode that the extraction part in embodiment of this invention extracts a path | pass and a method from a packet. It is a figure for demonstrating a mode that the extraction part in embodiment of this invention specifies API from API_DB. It is a figure for demonstrating a mode that the extraction part in embodiment of this invention acquires an extraction rule from Extract_Rules_DB. It is a figure for demonstrating a mode that the extraction part in embodiment of this invention extracts a parameter from a packet. It is a figure for demonstrating a mode that the replacement part in embodiment of this invention acquires a packet from API_Flow_DB. It is a figure for demonstrating a mode that the replacement part in embodiment of this invention acquires a replacement rule from Replacement_Rules_DB. It is a figure for demonstrating a mode that the replacement part in embodiment of this invention replaces the parameter in a packet. It is a figure which shows application cooperation using REST. It is a figure which shows the system architecture example for API publication | publishing.

  Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings. The following embodiments exemplify API conversion adapters for embodying the technical idea of the present invention, and the configuration of the apparatus and the configuration of data are limited to the following embodiments. is not.

(API conversion adapter function)
FIG. 1 is a diagram for explaining an API conversion adapter function according to an embodiment of the present invention. The embodiment of the present invention relates to an architecture for converting an existing system into a REST API in order to utilize an existing system that has not been converted into an API in general-purpose REST.

  As shown in FIG. 1, there are existing systems such as a call control server 41, a guidance server 42, a guidance setting server 43, a database server 44, a system 45, and a mail server 46. SIP is used for the call control server 41, FTP is used for the guidance server 42, HTTP is used for the guidance setting server 43, JDBC is used for the database server 44, and SNMP is used for the system 45. The mail server 46 uses SMTP and POP.

  Therefore, the API conversion adapter function in the embodiment of the present invention performs conversion processing according to various protocols, and converts the existing system into a general-purpose REST API. As a result, a common architecture is provided between APIs, and versatility is enhanced. In addition, by unifying the procedures in the API conversion adapter and performing module division according to the procedures, the readability is improved, the modules are reused, and the quality is stabilized.

(Classification of methods for converting existing systems into REST APIs)
FIG. 2 is a diagram showing three realization methods 1 to 3 for converting the existing system 40 into the REST API in the embodiment of the present invention.

  As shown in FIG. 2A, the implementation method 1 is a method in which an API module 30a or the like provided by middleware such as a database is applied to the existing system 40. In other words, it is an application of an API wrapper module provided by existing middleware.

  The merit of the implementation method 1 is that the existing system 40 can be used effectively, and the product (specification) change of the API gateway 20 is not affected. On the other hand, the disadvantage of the implementation method 1 is that the middleware providing the API module 30a is limited, and the existing system 40 needs to be remodeled so that it is expensive.

  As shown in FIG. 2B, the realization method 2 is a method of developing a cooperation function between OSS middleware and API software attached to Linux (registered trademark) as an API conversion adapter 30b. In other words, it is program conversion utilizing open source software (OSS).

  Advantages of the realization method 2 are that the existing system 40 is not required to be modified, the product (specifications) of the API gateway 20 is not affected, and the cost can be reduced by utilizing the OSS. On the other hand, the disadvantage of the implementation method 2 is that it is necessary to cope with each protocol. This demerit can be eliminated by a method described later. Although details will be described later, by using a packet, it is possible to cope with a protocol expressed by the packet.

  The implementation method 3 is a method of creating an IF conversion scenario attached to the API gateway 20 (a method of combining prepared parts) as shown in FIG. In other words, the IF conversion function 30c of the commercial API gateway 20 is used.

  The merit of the realization method 3 is that the existing system 40 is not required to be modified, and a scenario generation component prepared in advance in the API gateway 20 is used to reduce the amount of mounting. On the other hand, the disadvantage of the implementation method 3 is that if the API gateway 20 is changed to a new product, development on the API gateway 20 is required again, and the non-Web systems that can be handled are limited (depending on the API gateway 20 product) There is a point).

(Establishment of conversion processing technology that can support various protocols in general)
Conventionally, as for the existing system 40 that is not converted to API, as shown in FIG. 3A, packets are transmitted and received between the existing system 40 and the application 10A. On the other hand, the API conversion adapter 30 in the embodiment of the present invention stores a packet transmission / reception sequence between the existing system 40 and the application 10B in a database (DB) in advance as shown in FIG. Using the packet, only the parameter part is extracted and replaced. In this way, by using a packet, it is possible to easily implement an API.

(API conversion adapter)
FIG. 4 is a functional block diagram showing an example of the API conversion adapter 30 in the embodiment of the present invention. Here, it is assumed that the existing system 40 is connected to a telecommunications carrier network managed by a telecommunications carrier that provides services such as telephone. The API gateway 20 is a device that provides an API 21 for controlling the existing system 40 from the application 10 side on the external network. The API conversion adapter 30 is a device corresponding to the API conversion adapter 30b in the implementation method 2, and is deployed between the API gateway 20 and the existing system 40 (more specifically, the front side of the communication carrier network). .

  In creating the API conversion adapter 30, in order to support various functions and various protocols, (1) a common structure between APIs and (2) easy addition of APIs are designed. To do. By combining DB and WADL (Web Application Description Language), a general-purpose REST API can be realized.

  As shown in FIG. 4, the API conversion adapter 30 includes extraction units 31 and 34, replacement units 32 and 35, a client unit 33, and a storage unit 36. The storage unit 36 stores various DBs in advance. The extraction units 31 and 34 acquire the extraction rule from the DB, and extract the parameters in the received packet based on the extraction rule acquired from the DB. The replacement units 32 and 35 acquire a replacement rule and a transmission packet in the direction of the existing system 40 or the application 10 from the DB, and extract a parameter in the packet acquired from the DB based on the replacement rule acquired from the DB. , 34 to replace the extracted parameters. In FIG. 4, the upper extraction unit 31 and replacement unit 32 process packets transmitted in the right direction (from the application 10 toward the existing system 40), and the lower extraction unit 34 and replacement unit 35 operate in the left direction (existing Packets transmitted from the system 40 in the direction of the application 10) are processed. The client unit 33 performs packet transmission / reception with the existing system 40 using the packet replaced by the replacement unit 32.

  FIG. 5 is a configuration diagram of the DB stored in the storage unit 36 according to the embodiment of the present invention. As shown in this figure, the storage unit 36 stores an API_DB 36A, Extract_Rules_DB 36B, Replacement_Rules_DB 36C, and API_Flow_DB 36D.

  The API_DB 36A is a DB that stores API types. For example, API_DB 36A stores API_ID, API name, method, and path in association with each other. API_ID is an identifier of the API 21. The API name is the name of the API 21.

  Extract_Rules_DB 36B is a DB that stores parameter portions to be extracted. For example, Extract_Rules_DB 36B stores API_ID, flow serial number, extract serial number, and extraction rule in association with each other. The flow serial number is a serial number assigned to each packet. The extract serial number is a serial number assigned to each parameter to be extracted. The extraction rule is a rule for extracting a parameter in a packet, and is defined by a regular expression or a packet position.

  The Replacement_Rules_DB 36 </ b> C is a DB that stores parameter replacement portions for received packets. For example, the Replacement_Rules_DB 36C stores an API_ID, a flow serial number, a replacement serial number, and a replacement rule in association with each other. The replacement serial number is a serial number assigned to each parameter to be replaced. The replacement rule is a rule for replacing a parameter in a packet, and is defined by a regular expression or a packet position.

  The API_Flow_DB 36D is a DB storing a packet transmission / reception sequence performed in association with the API. For example, the API_Flow_DB 36D stores an API_ID, a flow serial number, and a packet in association with each other. The packet is a packet transmitted / received between the existing system 40 and the application 10.

  According to such an API conversion adapter 30, it is possible to receive a request and return a response with the API gateway 20 by REST, and to perform transmission and reception with the existing system 40 using an existing protocol. That is, API definition is described on the API gateway 20 side using WADL. The API with the existing system 40 side is a method for recording and generating protocol sequence data at the packet level, and therefore does not depend on a specific protocol.

  Here, the case where the realization method 2 is adopted is illustrated, but the same applies to the case where the other realization methods 1 and 3 are adopted. That is, when the implementation method 1 is adopted, the API conversion adapter 30 may be provided in the existing system 40, and when the implementation method 3 is adopted, the API conversion adapter 30 may be provided in the API gateway 20. . The term “adapter” used in this specification includes not only a case of being realized as a device but also a case of being realized as software.

  Moreover, although the case where the existing system 40 is connected to the telecommunications carrier network managed by the telecommunications carrier is illustrated here, the present invention is not limited to this. For example, the present technology can be applied to a game platform managed by an amusement company.

  In addition, here, the configuration including the API gateway 20 is illustrated, but the configuration is not limited thereto. That is, the present technology can be applied even when the API is directly disclosed without the API gateway 20.

(One-to-many communication)
FIG. 6 is a diagram showing a state in which a plurality of applications 10A and 10B use the existing system 40 using the API conversion adapter 30 according to the embodiment of the present invention. The application 10A uses the existing system 40 via the API 21A, and the application 10B uses the existing system 40 via the API 21B. The session_id “1” is used for communication between the application 10A and the existing system 40, and the session_id “2” is used for communication between the application 10B and the existing system 40.

(Specific examples of requests and responses)
FIG. 7 is a diagram illustrating a specific example of a request and a response when API conversion is performed using the API conversion adapter 30 according to the embodiment of the present invention. Here, the case where the audio file list acquisition API of the existing system 40 is used from the application 10 is illustrated.

  First, a request (GET) 61 is transmitted from the API gateway 20 to the API conversion adapter 30. A portion indicated in bold in the request (GET) 61 indicates a parameter portion extracted by the extraction unit 31.

  Next, a request (GET) 62 is transmitted from the API conversion adapter 30 to the existing system 40. The part shown in bold in this request (GET) 62 indicates the parameter part replaced by the replacement unit 32.

  Next, a response (HTML) 63 is transmitted from the existing system 40 to the API conversion adapter 30. The part shown in bold in this response (HTML) 63 indicates the parameter part extracted by the extraction unit 34.

  Finally, a response (JSON) 64 is transmitted from the API conversion adapter 30 to the API gateway 20. The part shown in bold in this response (JSON) 64 indicates the parameter part replaced by the replacement unit 35.

(Operation example of API conversion)
FIG. 8 is a flowchart showing an operation example when the API conversion is performed using the API conversion adapter 30 according to the embodiment of the present invention. In FIG. 8, steps S3A and S4A drawn on the left side are steps specific to the request flow, and step S4B drawn on the right side is a step specific to the response flow, and steps S1, S2, S5 drawn in the center S10 is a step common to the request flow and the response flow.

  First, when the extraction unit 31 receives a packet, the extraction unit 31 determines whether the packet has a method (S1 → S2). The methods are GET, POST, PUT, and DELETE used in HTTP.

  Next, when there is a method (S2: YES), the extraction unit 31 extracts a path and a method using a regular expression (S3A). Specifically, by using a regular expression such as “/(GET|POST|PUT|DELETE)¥s[a−zA−Z0−9¥/¥.¥−¥?]+¥s/”. 9, the path and the method “GET / nexttelapi / v1.0 / ms / 1 / voices” are extracted from the packet.

  Next, the extraction unit 31 queries the API_DB 36A and identifies the API (S4A). Specifically, as shown by reference numeral E1 in FIG. 10, the API_DB 36A is accessed using the path and method “GET / nexttelapi / v1.0 / ms / 1 / voices” extracted in step S3A, and the path and The API_ID “1” stored in association with the method is specified.

  On the other hand, if there is no method (S2: NO), the extraction unit 31 uses the session_id to identify the API (S4B). Specifically, the session_id is confirmed, and the API_ID held in the system is specified in association with the session_id.

  Next, the extraction unit 31 inquires Extract_Rules_DB 36B and acquires an extraction rule (S5). Specifically, as shown by reference numeral E2 in FIG. 11, by using the API_ID specified in step S4A or S4B, the flow serial number held in the system, and the extract serial number, the extraction rules “1 to 3” are extracted from the Extract_Rules_DB 36B. 6 bytes "is acquired.

  Next, the extraction unit 31 acquires a parameter in the packet from the extraction rule acquired in step S5 (S6). More specifically, as shown in bold in FIG. 12, the 1st to 6th byte destination MAC address “00 50 56 aa 13 39” as the header part is extracted.

  Next, the replacement unit 32 acquires a packet from the API_Flow_DB 36D (S7). Specifically, as shown by reference numeral E3 in FIG. 13, by using the API_ID specified in step S4A or S4B and the flow serial number held in the system, the packet “30 a4 23 80...” Is sent from the API_Flow_DB 36D. To get.

  Next, the replacement unit 32 acquires a replacement rule from the Replacement_Rules_DB 36C (S8). Specifically, as shown by reference numeral E4 in FIG. 14, by using the API_ID specified in step S4A or S4B, the flow serial number held in the system, and the replacement serial number, the replacement rule “7˜ 12 bytes "is acquired.

  Next, the replacement unit 32 applies the replacement rule acquired in step S8 to the packet acquired in step S7 and replaces it with the parameter acquired in step S6 (S9). Specifically, as shown in bold in FIG. 15, “23 54 13 a9 21 12” of the 7th to 12th bytes which is the header part of the packet “30 a4 23 80...” Is changed to “00 50 56 aa 13 39”. Replace.

  Finally, the client unit 33 transmits the packet replaced by the replacement unit 32 to the existing system 40 (S10). In FIG. 15, “06” indicates protocol information, and “1f 90” indicates a destination port number. The protocol information and the destination port number described in such a packet are used to perform packet transmission / reception with the existing system 40.

  As described above, the API conversion adapter 30 in the embodiment of the present invention is an API conversion adapter for converting the existing system 40 into an API, and stores a packet transmission / reception sequence with the existing system 40 in advance (a database ( A storage unit 36), an extraction unit 31 for extracting parameters in the received packet, a replacement unit 32 for replacing parameters in the packet stored in the database with the parameters extracted by the extraction unit 31, and a replacement unit 32 The client unit 33 that performs transmission / reception of the packet with the existing system 40 using the packet replaced by. In this way, by using the packet, it is possible to establish a conversion processing technique that can generally support various protocols as a method for converting the existing system 40 into a REST API.

  Here, the API conversion adapter 30 may be provided between the existing system 40 and the API gateway 20. Such an implementation method corresponds to the implementation method 2 described above. Advantages of the realization method 2 are that the existing system 40 is not required to be modified, the product (specifications) of the API gateway 20 is not affected, and the cost can be reduced by utilizing the OSS.

  Further, the API conversion adapter 30 receives a request and returns a response with the API gateway 20 by REST, and performs transmission / reception with the existing system 40 using an existing protocol. That is, since a packet transmission / reception sequence with the existing system 40 is stored in a database in advance and protocol information described in the packet is used, communication is possible without being limited to a specific protocol. In other words, conversion from REST API to all protocols that can be expressed at the packet level is possible.

  The API conversion system according to the embodiment of the present invention is an API conversion system for converting the existing system 40 into an API, and controls the existing system 40 and the existing system 40 from the application 10 side on the external network. API gateway 20 that provides the API 21 and any one of the API conversion adapters 30 described above. In this way, the existing system 40 can be converted to an API more easily by using the packet. In addition, transmission / reception of main packets is performed between the API conversion adapter 30 and the existing system 40, so that the amount of communication can be reduced.

  Note that the present invention can be realized not only as such an API conversion adapter 30 but also as an API conversion program that causes a computer to function as each of the characteristic function units included in the API conversion adapter 30. . Needless to say, such a program can be distributed via a recording medium such as a CD-ROM or a transmission medium such as the Internet.

10 ... Application 20 ... API Gateway 21 ... API
30 ... API conversion adapter 31, 34 ... Extraction unit 32, 35 ... Replacement unit 33 ... Client unit 36 ... Storage unit 36A ... API_DB
36B ... Extract_Rules_DB
36C ... Replacement_Rules_DB
36D ... API_Flow_DB
40 ... Existing system

In order to achieve the above object, the invention according to the first aspect is an API conversion adapter for converting an existing system into an API, and has received a database storing a packet transmission / reception sequence with the existing system in advance. An extraction unit for extracting a parameter in the packet; a replacement unit for replacing the parameter in the packet stored in the database with the parameter extracted by the extraction unit; and the packet replaced by the replacement unit, A client unit that performs transmission / reception of a packet with an existing system, and an API conversion adapter that performs request reception and response return with the API gateway and performs transmission / reception with the existing system with the existing system, The packet transmission / reception sequence with the existing system is stored in advance in the database. It may be stored, by using the protocol information described in the stored in the database packet, and summarized in that performing the conversion to all protocols that are represented at the packet level from REST.

An invention according to a third aspect is an API conversion system for converting an existing system into an API, the API gateway providing an API for controlling the existing system and the existing system from an application side on an external network And an API conversion adapter according to the first or second aspect.

The invention according to the fourth aspect is an API conversion program, and has a gist of causing a computer to function as each functional unit according to the first or second aspect.

Claims (5)

An API conversion adapter for converting an existing system into an API,
A database storing packet transmission / reception sequences with the existing system in advance;
An extractor for extracting parameters in the received packet;
A replacement unit that replaces the parameter in the packet stored in the database with the parameter extracted by the extraction unit;
An API conversion adapter comprising: a client unit that performs packet transmission / reception with the existing system using the packet replaced by the replacement unit.   The API conversion adapter according to claim 1, wherein the API conversion adapter is arranged between the existing system and an API gateway.   3. The API conversion adapter according to claim 2, wherein the API gateway performs request reception and response return by REST, and performs transmission and reception with the existing system using an existing protocol. 4. An API conversion system for converting an existing system into an API,
The existing system;
An API gateway that provides an API for controlling the existing system from an application side on an external network;
An API conversion system comprising: the API conversion adapter according to claim 1.   An API conversion program for causing a computer to function as each functional unit according to claim 1.

Images