WO2020031845A1 - Ａｐｉ仕様書生成装置、ａｐｉ仕様書生成方法、およびプログラム - Google Patents

Ａｐｉ仕様書生成装置、ａｐｉ仕様書生成方法、およびプログラム Download PDF

Info

Publication number
WO2020031845A1
WO2020031845A1 PCT/JP2019/030228 JP2019030228W WO2020031845A1 WO 2020031845 A1 WO2020031845 A1 WO 2020031845A1 JP 2019030228 W JP2019030228 W JP 2019030228W WO 2020031845 A1 WO2020031845 A1 WO 2020031845A1
Authority
WO
WIPO (PCT)
Prior art keywords
api
oas
unit
parameters
response
Prior art date
Application number
PCT/JP2019/030228
Other languages
English (en)
French (fr)
Inventor
真吾 小俣
Original Assignee
日本電信電話株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 日本電信電話株式会社 filed Critical 日本電信電話株式会社
Publication of WO2020031845A1 publication Critical patent/WO2020031845A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/73—Program documentation

Definitions

  • the present invention relates to an API specification generation device, an API specification generation method, and a program.
  • Each business provides an API (Application Program Interface) for managing services on the web, and users build and operate services through software that calls the API.
  • API Application Program Interface
  • the specifications of the API API name, URL (Uniform Resource Locator), parameters, etc. are defined by each business operator, and the user uses the API according to the rules.
  • Non-Patent Documents 1 and 2 As techniques for converting existing functions and API specifications into OAS (Open API spec) specifications, there are techniques described in Non-Patent Documents 1 and 2. Related technologies utilizing OAS include technologies described in Non-Patent Documents 3 to 5.
  • Non-Patent Document 1 describes a tool for automatically creating a Web API together with a document (Open API standard) from a database (DB).
  • Non-Patent Document 2 describes a tool for automatically creating a simple OAS specification from an API request-response.
  • Non-Patent Document 3 describes a technique for creating a Swagger Spec from a domain model such as a generation class diagram of a Swagger specification from an existence dependency graph.
  • Non-Patent Literature 4 describes a technique for analyzing parameters (such as an outline of an API and a method) specific to an API described in an API design document and detecting a Semantic error.
  • Non-Patent Document 5 when an API request is sent from a developed API using a tool called Newman according to a CTK (Conformance Test Kits) provided by TMF (TM Forum Member), it is checked whether the syntax is TMF-compliant. Tools to be described. This tool generates test results as html and json files.
  • FIGS. 12A and 12B are diagrams for explaining OAS specification creation.
  • FIG. 12A is an overall configuration diagram
  • FIG. 12B is an operation explanatory diagram.
  • FIG. 12A the notation indicated by a double line indicates an API (the same applies to each drawing below).
  • FIG. 13 is a diagram showing an example of an API request and an API response used in the simple OAS format creation tool of FIG. As shown in FIG.
  • a REST (REpresentational State Transfer) API 10 which is an interface is provided between an APL (Application) service (hereinafter referred to as an existing APL) 11 and an existing function 12 (hereinafter referred to as an existing function A12). Is provided.
  • the REST API 10 has no function corresponding to a protocol other than HTTP.
  • the request-response of the existing API is analyzed using a simple OAS format creation tool (see reference numeral a in FIG. 12A).
  • the API request-response 126 HTTP
  • the API request-response 126 includes an API request 124 and an API response 125 shown in FIG.
  • an OAS format (Function A OAS format 20) is generated for the function A using the simple OAS format creation tool.
  • the developer modifies the generated function A OAS format 20 with parameters and the like, and creates a function A OAS specification 21.
  • the function A OAS format 20 is slightly modified to create a function A OAS specification 21.
  • API Server Automatically generate REST API from the database at ultra-high speed, [online], [search on July 15, 2018], Internet ⁇ URL: https://www.cdata.com/jp/apiserver/> Swagger inspector, [online], [searched on July 15, 2018], Internet ⁇ URL: https://inspector.swagger.io/builder> Akio Ida and 2 others, "Generation of SWAGGER specifications from existence dependency graphs", IEICE Technical Report, KBSE2016-29 (2016-11) Shingo Omata, "A Study on API Design Support Method Based on API Description Rules", 14th NWS Workshop, Oct., 2017 CTK (Compatibility Test Kit), [online], [Search on July 15, 2018], Internet ⁇ URL: github.com/tmforum/CustomerManagementCTK>
  • Non-Patent Documents 1 to 5 also have the following problems.
  • the technique described in Non-Patent Document 1 can create a simple OAS limited to an area where parameters can be mechanically set from a specific DB, but cannot set parameters that cannot be uniquely specified.
  • Non-Patent Document 2 can create a simple OAS in which parameters are mechanically limited to a settable area, but even to a parameter (data type, value range, etc.) that cannot be uniquely specified. Cannot be set. In addition, it is impossible to form a parameter setting logic. Furthermore, it supports only HTTP and does not support other protocols.
  • Non-Patent Document 3 does not mention a technique for creating a Swagger @ Spec based on the result of the API request-response.
  • Non-Patent Document 4 is based on the premise that handwriting is performed for creating an OAS specification, and does not mention a function of analyzing a request response of an existing API and automatically generating an OAS specification. Further, the technology described in Non-Patent Document 4 is limited to a check rule for checking whether a customization area complies with a specific description rule. The technology described in Non-Patent Document 4 does not mention a function of creating an OAS specification based on the value of an API request-response parameter.
  • Non-Patent Document 5 is a tool that detects a Syntax error among specific description rules, and the technique described in Non-Patent Document 5 only confirms compliance with a specific rule. For this reason, with the technology described in Non-Patent Document 5, it is difficult to customize rules for checking compliance. Also, there is no technology for automatically generating Swagger @ Spec from the result of the request-response of the developed API.
  • Non-Patent Documents 1 to 5 there is no proposal of an automatic generation function of the OAS specification that reflects from the API request-response to the range of data types and values. There is no description of a function that ensures customizability that can support various protocols.
  • the present invention has been made in view of such a background, and the present invention provides an API specification generation device capable of creating an OAS specification, which is a REST @ API standard specification, at low cost based on an API request-response. It is an object to provide an API specification generation method and a program.
  • the invention according to claim 1 is an API specification document generation device that converts the specification of an existing API to generate an OAS specification document of a standard specification, and creates the OAS specification document.
  • An OAS template setting unit for setting a template file in advance an insertion value file setting unit for setting an insertion value file describing parameter setting logic used in the OAS specification, and an API request for capturing an API request and its response.
  • a response capture unit, the captured API request-response data, and the reference result of the insertion value file are reflected in the template file to set parameters, and the OAS specifications are created based on the set parameters.
  • An API specification creating device comprising: an OAS creating unit; It was.
  • an API specification generation device that converts an existing API specification to generate an OAS specification of a standard specification sets a template file when the OAS specification is created in advance. Setting an insertion value file describing parameter setting logic used in the OAS specification, capturing an API request and its response, capturing the API request-response data, and referring to the insertion value file And setting the parameters by reflecting the result in the template file and creating the OAS specifications based on the set parameters.
  • the invention according to claim 5 provides a computer as an API specification generation device that converts the specification of an existing API to generate an OAS specification of a standard specification, by using a template file for creating the OAS specification.
  • OAS template setting means for setting in advance insertion value file setting means for setting an insertion value file describing parameter setting logic used in the OAS specification
  • API request-response capture means for capturing an API request and its response captured API Request-response data and the reference result of the insertion value file are reflected in the template file to set parameters, and to function as OAS creating means for creating the OAS specifications based on the set parameters.
  • Program
  • OAS specification that reflects the data type and value range at low cost based on the API request-response.
  • a parameter setting logic that describes how to set parameters in the OAS from values of various protocols can be customized by the system operator.
  • unique parameters and protocols other than HTTP can be included in the OAS specification.
  • the invention according to claim 2 further comprises a parameter setting dictionary storage unit for storing a parameter setting dictionary for uniquely registering parameters in the OAS specification, wherein the OAS creating unit includes the captured API request-response data and Setting the provisional parameters by reflecting the reference result of the insertion value file in the template file, and referring to the captured API request-response data and the parameter setting dictionary, and setting the provisional parameters to the provisional parameters.
  • a parameter setting dictionary storage unit for storing a parameter setting dictionary for uniquely registering parameters in the OAS specification
  • the OAS creating unit includes the captured API request-response data and Setting the provisional parameters by reflecting the reference result of the insertion value file in the template file, and referring to the captured API request-response data and the parameter setting dictionary, and setting the provisional parameters to the provisional parameters.
  • an API description rule input unit for inputting an API description rule describing rules for designing an application programming interface, and an API for analyzing the API description rule and creating a check policy.
  • a description rule analysis unit ; and a compliance check processing unit that checks compliance with the API description rule based on the check policy.
  • the OAS creation unit is configured to send the created OAS specification to the The information is sent to a compliance check processing unit, and the compliance check processing unit checks compliance with the API description rule based on the OAS specification sent from the OAS creation unit.
  • the API specification document generation device was used.
  • an API specification generation device an API specification generation method, and a program that can generate an OAS specification at low cost based on an API request-response.
  • FIG. 1 is a configuration diagram illustrating an API specification document generation device according to an embodiment of the present invention.
  • FIG. 4 is a diagram illustrating an example of a template file set by an OAS template setting unit of the API specification document generation device according to the embodiment of the present invention.
  • FIG. 4 is a diagram illustrating an example of an insertion value file set by an insertion value file setting unit of the API specification document generation device according to the embodiment of the present invention.
  • FIG. 4 is a diagram illustrating an operation of an OAS creation unit of the API specification document generation device according to the embodiment of the present invention.
  • FIG. 4 is a diagram illustrating an OAS specification created by an operation of an OAS creating unit of the API specification creation device according to the embodiment of the present invention.
  • FIG. 7 is a diagram illustrating an example of a template file set by an OAS template setting unit when converting an SIP of the API specification document generation device according to the embodiment of the present invention into a REST @ API in an HTTP format.
  • FIG. 4 is a diagram illustrating an example of an insertion value file set by an insertion value file setting unit of the API specification document generation device according to the embodiment of the present invention.
  • FIG. 4 is a diagram illustrating an example in which a syntactic description rule is described in accordance with a comment style specified by an API specification document generation device according to an embodiment of the present invention.
  • FIG. 3 is a table showing API description rules of the API specification document generation device according to the embodiment of the present invention.
  • FIG. 4 is a diagram illustrating an example in which method usage rules are described in accordance with a description format defined by an API specification document generation device according to an embodiment of the present invention. It is a figure explaining OAS specification preparation of a prior art, (a) is the whole block diagram, (b) is an operation explanatory view.
  • FIG. 13 is a diagram illustrating an example of an API request and an API response used in the simple OAS format creation tool in FIG. 12.
  • FIGS. 1A and 1B are diagrams showing an outline of an API specification document generation device according to an embodiment of the present invention, wherein FIG. 1A is an overall configuration diagram, and FIG. The same components as those in FIGS. 12 and 13 are denoted by the same reference numerals.
  • the API specification document generating apparatus 100 automatically converts the specifications of the existing API into standard specification documents and generates them. As shown in FIG.
  • the API specification document generation device 100 is installed so as to capture an API request-response transmitted and received between the REST API 10 and the existing function 12 (details will be described later). As shown by a symbol d in FIG. 1B, the API request-response 126 captured by the capture block # 1 is output to the OAS generation processing block # 2.
  • the OAS generation processing block # 2 includes an OAS template setting unit 111 (described later), an insertion value file setting unit 112 (described later), and a parameter setting dictionary 123 (described later).
  • the reference result and parameters of the insertion value file 122 are reflected in the template file 121 prepared in advance according to the API guideline file including the parameter setting logic (see reference numeral e in FIG. 1B).
  • parameters are set by referring to the parameter setting dictionary 123 according to, for example, the parameter setting logic of the API guideline file (see reference numeral f in FIG. 1B).
  • the API specification generation device 100 also checks compliance with a specific API description rule. That is, as shown by reference numeral g in FIG. 1B, the OAS generated by the OAS generation processing block # 2 is output to the OAS output block # 3, and the compliance with a specific API description rule is also confirmed (described later). .
  • FIG. 2 is a configuration diagram illustrating the API specification document generation device according to the embodiment of the present invention.
  • the existing APL 11 is connected to an API providing device (existing function) 20 via a REST API 10 and an L2 (layer 2) switch 15.
  • the existing API 11 is used by the existing API developer 1.
  • the L2 switch 15 determines a relay destination based on a MAC (Media Access Control) address of a packet and performs a relay operation.
  • MAC Media Access Control
  • the $ API specification generation device 100 is installed between the REST @ API 10 and the API providing device 20.
  • the API specification document generating apparatus 100 automatically converts the specifications of the existing API into standard specification documents and generates them.
  • the API specification document generation device 100 receives an input from the existing API developer 2, an API request-response IF unit 101, an API request-response capture unit 102, an OAS creation unit 110, an OAS template setting unit 111, and an insertion.
  • a value file setting unit 112 and a parameter setting dictionary storage unit 113 are provided.
  • the OAS template setting unit 111, the insertion value file setting unit 112, and the parameter setting dictionary storage unit 113 receive an input from the API description rule creator / system operator 3.
  • the API specification document generation device 100 includes an API description rule setting method input unit 103, an API description rule input unit 104 that receives an input from the API description rule creator / system operator 3, an API description rule creator / system An API description rule analysis unit 105 that receives an input from the operator 4, a check policy setting unit 106, an API design editor unit 107 that receives an input from the existing API developer 5, and a compliance check processing unit 108.
  • the existing API developer 1, the existing API developer 2, and the existing API developer 5 may be the same developer.
  • the API description rule creator / system operator 3 and the API description rule creator / system operator 4 may be the same operator.
  • the API request-response IF unit 101 converts the input from the existing API developer 2 and sends it to the API providing device 20, and sets the API request-response capture unit 102 to capture the data of the API request-response.
  • the API providing device 20 returns a response to the transmission from the API request-response IF unit 101.
  • the API request-response data is specifically the value of each parameter (described later in detail) of the API request-response 126 (see FIG. 13).
  • the API request-response capture unit 102 captures an API request and an API request-response 126 (see FIG. 13) that is a response to the API request. 2, the API request / response capture unit 102 captures the API request / response 126 relayed by the L2 switch 15 and outputs the captured API request / response 126 to the OAS creating unit 110.
  • the OAS creation unit 110 sets the parameters by reflecting the captured API request-response 126 data (see FIG. 13) data and the reference result of the insertion value file 122 (see FIG. 4) in the template file 121 (see FIG. 3). Then, the OAS specification 127 (see FIG. 6) is created based on the set parameters.
  • the part to be changed according to the parameter of the API request-response 126 describes a conversion tag indicating a replacement part.
  • the OAS creating unit 110 sets provisional parameters by reflecting the captured API request-response data and the reference result of the insertion value file 122 in the template file 121, and sets the captured API request-response data and parameter With reference to the setting dictionary 123 (see FIG. 5), the provisional parameters are set to parameters with higher accuracy, and the OAS specification 127 is created based on the set parameters.
  • the OAS creating unit 110 does not uniquely determine the API request-response 126 (see FIG. 13) alone, and in the area where the parameter setting dictionary 123 needs to be referred, the reference command to the corresponding OAS tag part is added to the dictionary. Describe. Note that, depending on how to write the parameter setting logic described in the insertion value file 122, protocols other than HTTP can be automatically reflected in the OAS specification 127 (see FIG. 8 described later).
  • the OAS template setting unit 111 sets an OAS template (model file 121) (see FIG. 3) for creating the OAS specification 127 (see FIG. 6) in advance.
  • the template file 121 describes the replacement location as a conversion tag.
  • the insertion value file setting unit 112 sets the insertion value file 122 (see FIG. 4) describing the parameter setting logic used in the OAS specification 127 (see FIG. 6).
  • the insertion value file 122 has parameter setting logic to be reflected in the template file 121.
  • the insertion value file setting unit 112 sets an insertion value file 122 corresponding to the conversion tag described in the template file 121 (see FIG. 3).
  • the parameter setting dictionary storage unit 113 stores a parameter setting dictionary 123 (see FIG. 5) that registers parameters that are difficult to reflect uniquely in the OAS specifications 127 (see FIG. 6).
  • the API description rule setting method input unit 103 inputs a description style of the API description rule.
  • the API description rule creator / system operator 4 preliminarily inputs the API description rule description format to the API description rule setting method input unit 103.
  • the API description rule input unit 104 inputs an API description rule in which rules for designing an application programming interface are described.
  • the API description rule input unit 104 is described by the API description rule creator / system operator 3 in accordance with a general programming language such as an annotation or a regular expression, or a description format specific to the API specified by the API specification document generation device 100.
  • the API description rules are a syntax-like API description rule and a semantic API description rule described in accordance with a description format specified by the API specification document generation device 100.
  • the Syntax error is a syntax / grammar error.
  • the semantic error is an error caused by a difference in meaning or inconsistency, such as whether a used method complies with the concept of CRUD (Create, Read, Update, Delete) in an area related to design of API specifications.
  • the API description rule creator / system operator 3 inputs a source code or the like describing a check policy.
  • the API description rule analysis unit 105 analyzes the API description rule and creates a check policy. More specifically, the API description rule analysis unit 105 analyzes the API description rules and creates a check policy according to a description format specified in advance by the API description rule setting method input unit 103. The created check policy is sent to the check policy setting unit 106.
  • the check policy setting unit 106 confirms that the API description rule creator / system operator 4 has no mistake in the check policy. When it is confirmed that there is no mistake in the check policy, the check policy setting unit 106 reflects the check policy on the compliance check processing unit 108.
  • the API design editor unit 107 allows the existing API developer 5 to input an API design document.
  • the conformity check processing unit 108 checks that it conforms to the API description rule based on the check policy.
  • the compliance check processing unit 108 checks compliance with the API description rules based on the OAS specification 127 sent from the OAS creating unit 110. Specifically, the compliance check processing unit 108 receives an input of the API design document from the existing API developer 5, checks the input API design document based on the check policy, and checks the non-compliant non-compliant The location is notified to the existing API developer 5.
  • the API description rule creator / system operator 3 may input an API design document using the API design editor unit 107, or may send an API design document using the API provided by the API specification document generation device 100. You may. When the API description rule creator / system operator 3 uses the API design editor unit 107, the non-compliant part of the API design document is output to the API design editor unit 107 and notified to the existing API developer 5.
  • the API request-response IF unit 101 and the API request-response capture unit 102 in FIG. 2 correspond to the capture block # 1 in FIG.
  • the OAS creation unit 110, OAS template setting unit 111, insertion value file setting unit 112, and parameter setting dictionary storage unit 113 in FIG. 2 correspond to the OAS generation processing block # 2 in FIG. 1.
  • FIG. 3 is a diagram illustrating an example of the template file 121 set by the OAS template setting unit 111.
  • the template file 121 is a template for creating the OAS specification 127 (see FIG. 6) according to the value of each parameter of the API request-response 126 (see FIG. 13).
  • the template file 121 describes the replacement location as a conversion tag.
  • a conversion tag indicating a replacement portion is described in a portion that is changed according to the parameter of the API request-response 126.
  • a replacement part (see bold characters in FIG. 3) indicated by “!” Is described as a conversion tag.
  • FIG. 4 is a diagram illustrating an example of the insertion value file 122 set by the insertion value file setting unit 112.
  • the insertion value file 122 has parameter setting logic to be reflected in the template file 121 (see FIG. 3).
  • the parameter area that cannot be uniquely specified is determined by referring to the parameter setting dictionary 123 or the like.
  • Host.yaml host [Host:] directly reflects the contents of the Host: header of the request-response.
  • BasePath.yaml basePath [Request URI:-Host:] refers to each parameter of the request parameter and sets how to reflect the request in the OAS.
  • logic for setting a value obtained by subtracting the value of the Host: header from the value of the Request URL header as basePath: is described.
  • FIG. 5 is a diagram illustrating the operation of the OAS creating unit 110.
  • the operation of the OAS creating unit 110 will be described later, and a configuration example of the parameter setting dictionary 123 will be described.
  • the parameter setting dictionary 123 uniquely registers parameters that are difficult to reflect in the OAS specifications 127 (see FIG. 6).
  • the parameter setting dictionary 123 has Type (format), format, maximum (maximum value), and minimum (minimum value) corresponding to Word (item).
  • Word is, for example, Birthday, Telephone, Credit.
  • Type is, for example, integer.
  • the format is int32 (32-bit integer) and int64 (64-bit integer).
  • the type “integer”, the format “int32”, the maximum “99999999”, and the minimum “00” are referred to.
  • the maximum is set to yyyymmdd (4 digits of the Christian era, 2 digits of the month, 2 digits of the day) and the minimum is set to dd (2 digits of the day). For this reason, parameters larger than "00" (two digits) cannot be set in minimum.
  • Type “integer”, format “int32”, maximum “ ⁇ (no setting)”, and minimum “0000000000” (eight digits) are referred to.
  • the OAS creating unit 110 can set appropriate parameters with high accuracy even for parameters that cannot be set mechanically only by request-response analysis (described later).
  • the existing API developer 2 If there is no APL request, the existing API developer 2 inputs information (URL, request parameters, etc.) necessary for transmitting the API request to the existing API 11, as indicated by reference numeral i in FIG. The existing API developer 2 also checks the response result to the API request.
  • information URL, request parameters, etc.
  • the API request / response capture unit 102 captures the API request / response 126 (see FIG. 13) relayed by the L2 switch 15.
  • the API description rule creator / system operator 3 includes a template file 121 of the OAS template setting unit 111, an insertion value file 122 of the insertion value file setting unit 112, a parameter setting dictionary.
  • the template file 121, the insertion value file 122, and the parameter setting dictionary 123 are manually enriched or customized.
  • the OAS creating unit 110 stores the API request-response captured by the API request-response capture unit 102 in the template file 121 (see FIG. 3) set in the OAS template setting unit 111.
  • the captured data 126 and the reference result of the insertion value file setting unit 112 are reflected.
  • the OAS creating unit 110 tentatively refers to the parameter setting dictionary 123 (see FIG. 5) stored in the parameter setting dictionary storage unit 113 for parameters that are difficult to reflect uniquely in the OAS. Set the parameters manually.
  • the API description rule creator / system operator 3 inputs a general programming language such as an annotation or a regular expression, or an API specification
  • the user enters an API description rule described in accordance with an API-specific description format specified by the user.
  • the API description rule creator / system operator 3 describes the API description rules according to the description format set by the API description rule setting method input unit 103 (described later).
  • the API description rules are a syntax-like API description rule and a semantic API description rule described in accordance with a description format specified by the API specification document generation device 100.
  • the API description rules include rules that specify characters and character strings that are not allowed to be used for API resource names and parameter names, rules that specify how to use methods used in APIs, and the like.
  • rules of the REST API 10 can be defined by utilizing the limited characteristics.
  • the API description rule creator / system operator 3 inputs a source code or the like describing the check policy.
  • the API description rule setting method input unit 103 inputs a description style of the API description rule.
  • the description format of the API description rule is input in advance by the API description rule creator / system operator 4, for example.
  • the API description rule analysis unit 105 analyzes the API description rules according to the description format prescribed by the API description rule setting method input unit 103 and determines a check policy. The determined check policy is sent to the check policy setting unit 106.
  • the API description rule creator / system operator 4 uses the check policy setting unit 106 to confirm that the check policy is correct.
  • the check policy setting unit 106 reflects the check policy on the compliance check processing unit 108 (see reference numeral q in FIG. 2).
  • the OAS creating unit 110 inputs the created OAS to the API design editor unit 107.
  • the API design editor unit 107 displays the contents created as OAS.
  • the API design editor unit 107 displays the OAS created by the OAS creating unit 110, and assists the existing API developer 5 in designing and writing an API design document.
  • the compliance check processing unit 108 receives an input of the API design document (OAS) from the existing API developer 5, and converts the input API design document (OAS) based on the check policy. It checks and notifies the existing API developer 5 of a non-compliant part that does not conform to the check policy (see reference numeral u in FIG. 2).
  • the existing API developer 5 inputs an API design document (OAS) using the API design editor unit 107.
  • the compliance check processing unit 108 by sending an OAS to the compliance check processing unit 108 via the API design editor unit 107, the compliance check processing unit 108 Compliance checks can also be confirmed.
  • the specific API description rules include those that cannot be checked for compliance in the description format of the API description rules input by the API description rule setting method input unit 103.
  • the compliance check processing unit 108 proposes a design content compliant with a specific API description rule to the existing API developer 5 (see reference numeral u in FIG. 2).
  • the operation of the OAS creating unit 110 will be described with reference to FIG.
  • the OAS creation unit 110 (see FIG. 2) reflects the data of the API request-response 126 captured by the API request-response capture unit 102 (see FIG. 2) in the insertion value file 122 according to the parameter setting logic.
  • Host.yaml “host:” and “basePath:” are set in the parameter setting logic. Therefore, as shown by the symbol z in FIG. 5, host.yaml remains as host: petstore-api.herokuapp.com of the API request 124 (see FIG. 13). Similarly, basePath.yaml becomes basePath: / Pet.
  • the OAS creation unit 110 sets provisional parameters by reflecting the captured data of the API request-response 126 and the reference result of the insertion value file 122 in the template file 121.
  • host.yaml is a parameter that cannot be set mechanically only by analyzing the API request-response (a parameter that cannot be uniquely specified).
  • each parameter is set for “.name_1.yaml”, “type_1.yaml”, and “format_1.yaml” with reference to the parameter setting dictionary 123, The design is reflected in the insertion value file 122.
  • the parameter setting dictionary 123 shown in FIG. 5 has Type, format, maximum, and minimum corresponding to Word. As shown by the reference numeral b1 in FIG. Is done. That is, ⁇ Name_1.yaml birthday: ⁇ Type_1.yaml type: integer ⁇ Format_1.yaml format: int32 Is set in the insertion value file 122.
  • the OAS creation unit 110 refers to the captured data of the API request-response 126 and the parameter setting dictionary 123 and sets the provisional parameters to parameters with higher accuracy. In other words, parameters that are difficult to reflect uniquely in the OAS are set with higher accuracy by referring to the parameter setting dictionary 123.
  • FIG. 6 is a diagram showing the OAS specification 127 created by the operation of the OAS creating unit 110 in FIG.
  • the OAS specification 127 shown in FIG. 6 indicates a file in which the insertion value file 122 (see FIG. 5) has been inserted into the template file 121 (see FIG. 3).
  • Bold characters in FIG. 6 refer to the capture data of the API request-response 126 and the parameter setting dictionary 123, and reflect the design in the template file 121 (see FIG. 3).
  • the OAS specification 127 shown in FIG. 6 is based on the template file 121 (see FIG. 3).
  • FIG. 7 is a diagram illustrating an example of the template file 121A set by the OAS template setting unit 111 when converting the SIP into the REST API in the HTTP format.
  • the same parts as those in the template file 121 in FIG. 3 are assigned the same parameters.
  • the template file 121A is a template for creating an OAS specification according to the value of each parameter of the API request-response 126 (see FIG. 13).
  • a conversion tag indicating a replacement portion is described in a portion changed according to the parameter of the API request-response 126.
  • the OAS creating unit 110 sets an insertion value file 122A (see FIG. 8) corresponding to the conversion tag described in the template file 121A.
  • the template file 121A shown in FIG. The following parameters of the template file 121 shown in FIG. ! ! Conversion name_1: ! ! Conversion type_1: ! ! Conversion format_1 ! ! Conversion name_2: ! ! Conversion type_2: ! ! Conversion format_2: Has the following parameters properties: from ! ! Conversion type_1: ! ! Conversion format_1 to ! ! Conversion type_2: ! ! Conversion format_2: Has been replaced by
  • FIG. 8 is a diagram illustrating an example of the insertion value file 122A set by the insertion value file setting unit 112.
  • the insertion value file 122A is a file having parameter logic to be reflected in the template file 121A (see FIG. 7).
  • the parameter area that cannot be uniquely specified is determined by referring to a parameter setting dictionary.
  • the insertion value file 122A shown in FIG. Host.yaml host: [REGISTER sip:] ⁇ Method.yaml - [REGESTER: post] - [INVITE: get] ⁇ Type_1.yaml [To:] Having.
  • Host.yaml host [REGISTER sip:] is an example in which the SIP URI of the request by the REGESTER method for making a registration request to the proxy in the network is the host part of HTTP.
  • Type_1.yaml [To:] is an example where the value of the To: header of SIP INVITE is reflected.
  • FIG. 9 is a diagram showing an example in which a syntactical description rule is described in accordance with a comment style specified by the API specification document generation device 100.
  • a file described by utilizing a regular expression or the like using a description format designated by the specification generation device 100 is imported into the API description rule input unit 104 (see FIG. 2) (see reference numeral i1 in FIG. 9).
  • the compliance check processing unit 108 defines a compliance check policy according to the described contents.
  • the API design editor unit 107 confirms the compliance of the described API specification according to a check policy defined in advance, and compares the result with an existing API developer. Notify 5
  • the notification format is notified by the API design editor unit 107 in real time.
  • FIG. 10 is a table showing the API description rules.
  • the table shown in FIG. 10 defines the usage of each method as an API description rule.
  • a method name POST, GET, PUT, DELETE
  • a corresponding use are defined for each CRUD (Create, Read, Update, Delete).
  • CRUD Create, Read, Update, Delete
  • the usage of each method is specified in the table of FIG. 10 as an API description rule. For example, it is checked whether “GET” is used in spite of an API for newly creating / updating / deleting a resource. An error is output when a method that is not suitable for the purpose is used contrary to the rules specified in the table of FIG.
  • FIG. 11 is a diagram illustrating an example in which method usage rules are described in accordance with a description format defined by the API specification document generation device 100.
  • “@NGcheck ⁇ Api” is a rule that outputs an error when there is a description that meets a specific condition in the design (outline or method) of an API for each endpoint. (Policy).
  • Policy Policy
  • FIG. 11 a policy for outputting an error in a description format defined by the API specification document generation device 100 is described. For example, when the description (description section) of the API includes descriptions of “update”, “create”, “add”, “add”, “delete”, and “delete” and uses the GET method, Output an error.
  • the API design document describes that a GET method is used in a certain line, and that the description of the API in a subsequent line includes “Create”.
  • This API design document uses GET despite the API for creating a new resource. Therefore, when this API design document is input to the API specification document generation device 100, error information indicating that a method not suitable for the purpose is used is output.
  • the API specification document generation device 100 includes the OAS template setting unit 111 that previously sets the template file 121 when creating the OAS specification 127, and the OAS specification 127 Insertion value file setting unit 112 for setting an insertion value file 122 that describes parameter setting logic used in API, API request-response capture unit 102 for capturing an API request and its response, captured API request-response data, and insertion
  • An OAS creating unit 110 that sets parameters by reflecting the reference result of the value file 122 in the template file 121 and creates an OAS specification 127 based on the set parameters.
  • the API specification document generation device 100 includes a parameter setting dictionary storage unit 113 that stores a parameter setting dictionary 123 for registering a parameter that is difficult to reflect uniquely in the OAS specification document 127.
  • the provisional parameters are set by reflecting the data of the API request-response 126 and the reference result of the insertion value file 122 in the template file 121, and the data of the captured API request-response 126 and the parameter setting dictionary are referred to. Then, the provisional parameters are set to more accurate parameters, and the OAS specification 127 is created based on the set parameters.
  • each of the above-described configurations, functions, and the like may be partially or entirely realized by hardware, for example, by designing an integrated circuit. Further, each of the above-described configurations, functions, and the like may be realized by software that causes a processor to interpret and execute a program that realizes each function. Information such as programs, tables, and files for realizing each function is stored in a memory, a hard disk, a recording device such as an SSD (Solid State Drive), an IC (Integrated Circuit) card, an SD (Secure Digital) card, an optical disk, or the like. It can be stored in a recording medium.
  • SSD Solid State Drive
  • IC Integrated Circuit
  • SD Secure Digital
  • processing steps describing time-series processing include, in addition to processing performed in a time-series manner in the order described, parallel or individual processing even if not necessarily performed in a time-series manner. (For example, parallel processing or processing by an object).

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Library & Information Science (AREA)
  • Stored Programmes (AREA)

Abstract

ＡＰＩリクエスト－レスポンスをもとに低コストでＯＡＳ仕様書を作成できるＡＰＩ仕様書生成装置、ＡＰＩ仕様書生成方法、およびプログラムを提供する。ＡＰＩ仕様書生成装置１００は、ＯＡＳ仕様書１２７を作成する際の雛形ファイル１２１をあらかじめ設定するＯＡＳ雛形設定部１１１と、ＯＡＳ仕様書１２７で用いるパラメータ設定ロジックを記述する挿入値ファイル１２２を設定する挿入値ファイル設定部１１２と、ＡＰＩリクエストとそのレスポンスをキャプチャするＡＰＩリクエスト－レスポンスキャプチャ部１０２と、キャプチャしたＡＰＩリクエスト－レスポンスデータと、挿入値ファイル１２２の参照結果とを雛形ファイル１２１に反映してパラメータを設定し、設定したパラメータをもとにＯＡＳ仕様書１２７を作成するＯＡＳ作成部１１０と、を備える。

Description

ＡＰＩ仕様書生成装置、ＡＰＩ仕様書生成方法、およびプログラム
　本発明は、ＡＰＩ仕様書生成装置、ＡＰＩ仕様書生成方法、およびプログラムに関する。
　各事業者がサービスを管理するためのＡＰＩ（Application Program Interface）をウェブ上にて提供しており、ユーザはＡＰＩを呼び出すソフトウェアを通じてサービスを構築・運用している。ＡＰＩの仕様（ＡＰＩの名称、ＵＲＬ（Uniform Resource Locator）、パラメータ等）は、各事業者が規定しており、ユーザは当該規定に従ってＡＰＩを使用する。
　既存機能やＡＰＩ仕様をＯＡＳ（Open API spec）仕様に変換する技術として、非特許文献１，２に記載された技術がある。また、ＯＡＳを活用した関連技術には、非特許文献３～５に記載された技術がある。
　非特許文献１には、データベース（ＤＢ）からWeb APIをドキュメント(Open API標準)と共に自動作成するツールが記載されている。
　非特許文献２には、ＡＰＩリクエスト－レスポンスから簡易的なＯＡＳ仕様書を自動作成するツールが記載されている。
　非特許文献３には、存在従属グラフからSwagger仕様書の生成クラス図のようなドメインモデルからSwagger Specを作成する技術が記載されている。
　非特許文献４には、ＡＰＩ設計書に記載されているＡＰＩ特有のパラメータ（ＡＰＩ概要、メソッド等）を解析し、Semantic的エラーを検出する技術が記載されている。
　非特許文献５には、開発済のＡＰＩを、ＴＭＦ（TM Forum members）提供のＣＴＫ（Conformance Test Kits）に従いNewmanというツールを用いてＡＰＩリクエストを送ると、Syntax的にＴＭＦ準拠になっているかチェックするツールが記載されている。このツールは、テスト結果をhtmlやjsonファイルとして生成する。
　ＯＡＳベースで設計／（「／」は、「および／または」、を表記する。以下同様。）開発されていない既存ＡＰＩ（以降、「既存ＡＰＩ」という)仕様を標準仕様書であるＯＡＳ形式にする場合について説明する。
　図１２は、ＯＡＳ仕様書作成を説明する図であり、（ａ）はその全体構成図、（ｂ）はその動作説明図である。図１２（ａ）中、二重線で示される表記は、ＡＰＩを示す（以下、各図において同様）。図１３は、図１２の簡易ＯＡＳフォーマット作成ツールで用いるＡＰＩリクエストおよびＡＰＩレスポンスの一例を示す図である。
　図１２（ａ）に示すように、ＡＰＬ（Application）サービス（以下、既存ＡＰＬという）１１と既存機能１２（既存機能Ａ１２という）との間には、インターフェースであるＲＥＳＴ（REpresentational State Transfer） ＡＰＩ１０が設けられている。なお、ＲＥＳＴ ＡＰＩ１０は、ＨＴＴＰ以外のプロトコルに対応した機能はない。
　既存ＡＰＩからＯＡＳ仕様書を作成する場合、簡易ＯＡＳフォーマット作成ツール（図１２（ａ）の符号ａ参照）を用いて、既存ＡＰＩのリクエスト－レスポンスを解析する。例えば、図１２（ｂ）に示すＡＰＩリクエスト－レスポンス１２６（ＨＴＴＰ）を解析する。ＡＰＩリクエスト－レスポンス１２６は、図１３に示すＡＰＩリクエスト１２４およびＡＰＩレスポンス１２５からなる。
　図１２（ｂ）の符号ｂに示すように、簡易ＯＡＳフォーマット作成ツールを用いて、機能ＡについてＯＡＳ形式のフォーマット（機能Ａ ＯＡＳフォーマット２０）を生成する。
　図１２（ｂ）の符号ｃに示すように、開発者が、生成された機能Ａ ＯＡＳフォーマット２０に対してパラメータ等の修正を加えて、機能Ａ ＯＡＳ仕様書２１を作成する。
　機能Ａ ＯＡＳフォーマット２０に、微修正を加えて、機能Ａ ＯＡＳ仕様書２１を作成している。
API Server: データベースからREST API を超高速で自動生成,［online］,［平成３０年７月１５日検索］,インターネット 〈URL: https://www.cdata.com/jp/apiserver/〉 Swagger inspector,［online］,［平成３０年７月１５日検索］,インターネット 〈URL: https://inspector.swagger.io/builder〉 井田明男，他２名，「存在従属グラフからSWAGGER仕様書の生成」，信学技報, IEICE Technical Report KBSE2016-29(2016-11) 小俣真吾，「API記述ルールに準拠したAPI設計支援方法に関する一検討」，第14 回NWS 研究会，Oct., 2017 CTK(Compatibility Test Kit),［online］,［平成３０年７月１５日検索］,インターネット 〈URL: github.com/tmforum/CustomerManagementCTK〉
　上述したように、既存のＲＥＳＴ ＡＰＩのＡＰＩリクエスト－レスポンス１２６の解析のみで簡易なＯＡＳ仕様書２１の作成は可能である。
　しかしながら、（１）単純なＡＰＩリクエスト－レスポンス１２６のみの解析では、ＯＡＳの仕様を決められないパラメータ（データ型、データ範囲、値の最大値／最小値等）が存在する。例えば、データ型（“string”，“number”，“integer”，“boolean”，“array”等）の決定や値の範囲（maximum　minimum）を一意に特定してＯＡＳに反映させるのは難しく、加筆修正する必要がある。そのため、ＯＡＳ仕様書を自動生成させても、ＯＡＳ仕様書を修正する稼働が発生する。また、ＨＴＴＰ（Hypertext Transfer Protocol）以外のプロトコルに対応したＯＡＳ仕様書の自動生成技術は存在しない。
　（２）ＡＰＩリクエスト－レスポンス１２６のデータから、どのようなロジックでＯＡＳパラメータに反映するかのルールを設定する機能は存在しない。このため、各社独自パラメータやＨＴＴＰ以外のプロトコルに対応できていない。
　以上の理由から、非特許文献１～５に記載された技術ついても下記の課題がある。
　非特許文献１に記載の技術は、特定のＤＢから機械的にパラメータを設定可能な領域に限定した簡易なＯＡＳを作成することはできるものの、一意に特定不可なパラメータまでは設定できない。また、パラメータ設定のロジックを組むことも不可である。
　非特許文献２に記載の技術は、パラメータを機械的に、設定可能な領域に限定した簡易なＯＡＳを作成することはできるものの、一意に特定不可なパラメータ（データ型、値の範囲等）までは設定できない。また、パラメータ設定のロジックを組むことも不可である。さらに、ＨＴＴＰのみに対応であり、他のプロトコルに対応していない。
　非特許文献３に記載の技術は、ＡＰＩリクエスト－レスポンスの結果をもとに、Swagger Specを作成する技術については触れられていない。
　非特許文献４に記載の技術は、ＯＡＳ仕様書の作成について手書きを前提としており、既存ＡＰＩのリクエストレスポンスを解析してＯＡＳ仕様書を自動生成する機能には触れられていない。また、非特許文献４に記載の技術は、カスタマイズ領域が特定の記述ルールに準拠しているか否かをチェックするチェックルールに限定されている。非特許文献４に記載の技術は、ＡＰＩリクエスト－レスポンスパラメータの値をもとにＯＡＳ仕様書を作成する機能については触れられていない。
　非特許文献５に記載の技術は、特定の記述ルールのうちSyntaxエラーを検出するツールであり、非特許文献５に記載の技術は、特定のルールへの準拠性を確認するのみである。このため、非特許文献５に記載の技術では、準拠性を確認するルールのカスタマイズは難しい。また、開発済ＡＰＩのリクエスト－レスポンスの結果からSwagger Specを自動生成する技術は具備していない。
　上記非特許文献１～５のいずれの技術についても、ＡＰＩリクエスト－レスポンスからデータ型や値の範囲まで反映するＯＡＳ仕様書の自動生成機能は提案されていない。様々なプロトコルに対応可能なカスタマイズ性を担保した機能も述べられていない。
　このような背景に鑑みて本発明がなされたのであり、本発明は、ＡＰＩリクエスト－レスポンスをもとに低コストでＲＥＳＴ ＡＰＩの標準仕様書であるＯＡＳ仕様書を作成できるＡＰＩ仕様書生成装置、ＡＰＩ仕様書生成方法、およびプログラムを提供することを課題とする。
　前記した課題を解決するため、請求項１に記載の発明は、既存ＡＰＩの仕様を変換して標準仕様のＯＡＳ仕様書を生成するＡＰＩ仕様書生成装置であって、前記ＯＡＳ仕様書を作成する際の雛形ファイルをあらかじめ設定するＯＡＳ雛形設定部と、前記ＯＡＳ仕様書で用いるパラメータ設定ロジックを記述する挿入値ファイルを設定する挿入値ファイル設定部と、ＡＰＩリクエストとそのレスポンスをキャプチャするＡＰＩリクエスト－レスポンスキャプチャ部と、キャプチャしたＡＰＩリクエスト－レスポンスデータと、前記挿入値ファイルの参照結果とを前記雛形ファイルに反映してパラメータを設定し、設定した前記パラメータをもとに前記ＯＡＳ仕様書を作成するＯＡＳ作成部と、を備えることを特徴とするＡＰＩ仕様書生成装置とした。
　また、請求項４に記載の発明は、既存ＡＰＩの仕様を変換して標準仕様のＯＡＳ仕様書を生成するＡＰＩ仕様書生成装置が、前記ＯＡＳ仕様書を作成する際の雛形ファイルをあらかじめ設定するステップと、前記ＯＡＳ仕様書で用いるパラメータ設定ロジックを記述する挿入値ファイルを設定するステップと、ＡＰＩリクエストとそのレスポンスをキャプチャするステップと、キャプチャしたＡＰＩリクエスト－レスポンスデータと、前記挿入値ファイルの参照結果とを前記雛形ファイルに反映してパラメータを設定し、設定した前記パラメータをもとに前記ＯＡＳ仕様書を作成するステップと、を実行することを特徴とするＡＰＩ仕様書生成方法とした。
　また、請求項５に記載の発明は、既存ＡＰＩの仕様を変換して標準仕様のＯＡＳ仕様書を生成するＡＰＩ仕様書生成装置としてのコンピュータを、前記ＯＡＳ仕様書を作成する際の雛形ファイルをあらかじめ設定するＯＡＳ雛形設定手段、前記ＯＡＳ仕様書で用いるパラメータ設定ロジックを記述する挿入値ファイルを設定する挿入値ファイル設定手段、ＡＰＩリクエストとそのレスポンスをキャプチャするＡＰＩリクエスト－レスポンスキャプチャ手段、キャプチャしたＡＰＩリクエスト－レスポンスデータと、前記挿入値ファイルの参照結果とを前記雛形ファイルに反映してパラメータを設定し、設定した前記パラメータをもとに前記ＯＡＳ仕様書を作成するＯＡＳ作成手段、として機能させるためのプログラムとした。
　このようにすることで、ＡＰＩリクエスト－レスポンスをもとに低コストでデータ型や値の範囲まで反映するＯＡＳ仕様書を作成できる。また、各種プロトコルの値から、ＯＡＳにパラメータをどのように設定するかを記述するパラメータ設定ロジックも、システム運用者にてカスタマイズ可能である。さらに、独自パラメータやＨＴＴＰ以外のプロトコルもＯＡＳ仕様書の対象にすることができる。
　また、請求項２に記載の発明は、一意にＯＡＳ仕様書へパラメータを登録するパラメータ設定辞書を格納するパラメータ設定辞書格納部をさらに備え、前記ＯＡＳ作成部は、キャプチャしたＡＰＩリクエスト－レスポンスデータと、前記挿入値ファイルの参照結果とを前記雛形ファイルに反映して暫定パラメータを設定するとともに、キャプチャしたＡＰＩリクエスト－レスポンスデータと、前記パラメータ設定辞書を参照して、前記暫定パラメータを、当該暫定パラメータよりも精度の高いパラメータに設定し、設定した前記パラメータをもとに前記ＯＡＳ仕様書を作成することを特徴とする請求項１に記載のＡＰＩ仕様書生成装置とした。
　このようにすることで、ＡＰＩリクエスト－レスポンスとＡＰＩパラメータ設定辞書を参照して、一意に特定不可であるパラメータも高精度で設計可能となる。このため、ＯＡＳ仕様書の作成および修正稼働を削減することができる。
　また、請求項３に記載の発明は、アプリケーションプログラミングインタフェースを設計する際のルールを記述したＡＰＩ記述ルールを入力するＡＰＩ記述ルール入力部と、前記ＡＰＩ記述ルールを解析してチェックポリシーを作成するＡＰＩ記述ルール解析部と、前記チェックポリシーに基づいて前記ＡＰＩ記述ルールに準拠していることをチェックする準拠性チェック処理部と、をさらに備え、前記ＯＡＳ作成部は、作成した前記ＯＡＳ仕様書を前記準拠性チェック処理部に送り、前記準拠性チェック処理部は、前記ＯＡＳ作成部から送られた前記ＯＡＳ仕様書をもとに、前記ＡＰＩ記述ルールへの準拠性をチェックすることを特徴とする請求項１に記載のＡＰＩ仕様書生成装置とした。
　このようにすることで、生成されたＡＰＩ仕様書について、特定のＡＰＩ記述ルールへの準拠性も確認することができる。
　本発明によれば、ＡＰＩリクエスト－レスポンスをもとに低コストでＯＡＳ仕様書を作成できるＡＰＩ仕様書生成装置、ＡＰＩ仕様書生成方法、およびプログラムを提供することができる。
本発明の実施形態に係るＡＰＩ仕様書生成装置の概要を示す図であり、（ａ）はその全体構成図、（ｂ）はその動作説明図である。 本発明の実施形態に係るＡＰＩ仕様書生成装置を示す構成図である。 本発明の実施形態に係るＡＰＩ仕様書生成装置のＯＡＳ雛形設定部が設定する雛形ファイルの一例を示す図である。 本発明の実施形態に係るＡＰＩ仕様書生成装置の挿入値ファイル設定部が設定する挿入値ファイルの一例を示す図である。 本発明の実施形態に係るＡＰＩ仕様書生成装置のＯＡＳ作成部の動作を示す図である。 本発明の実施形態に係るＡＰＩ仕様書生成装置のＯＡＳ作成部の動作により作成されたＯＡＳ仕様書を示す図である。 本発明の実施形態に係るＡＰＩ仕様書生成装置のＳＩＰをＨＴＴＰ形式のＲＥＳＴ ＡＰＩに変換する場合、ＯＡＳ雛形設定部が設定する雛形ファイルの一例を示す図である。 本発明の実施形態に係るＡＰＩ仕様書生成装置の挿入値ファイル設定部が設定する挿入値ファイルの一例を示す図である。 本発明の実施形態に係るＡＰＩ仕様書生成装置が規定する注釈様式に従って、構文的記述ルールを記載した例を示す図である。 本発明の実施形態に係るＡＰＩ仕様書生成装置のＡＰＩ記述ルールを表にして示す図である。 本発明の実施形態に係るＡＰＩ仕様書生成装置が規定する記述様式に従って、メソッド使用ルールを記載した例を示す図である。 従来技術のＯＡＳ仕様書作成を説明する図であり、（ａ）は全体構成図、（ｂ）は動作説明図である。 図１２の簡易ＯＡＳフォーマット作成ツールで用いるＡＰＩリクエストおよびＡＰＩレスポンスの一例を示す図である。
　以下、図面を参照して本発明を実施するための形態（以下、「本実施形態」という）におけるＡＰＩ仕様書生成装置等について説明する。
（原理説明）
　図１は、本発明の実施形態に係るＡＰＩ仕様書生成装置の概要を示す図であり、（ａ）はその全体構成図、（ｂ）はその動作説明図である。図１２および図１３と同一構成部分には同一符号を付している。
　ＡＰＩ仕様書生成装置１００は、既存ＡＰＩの仕様を自動で標準仕様の仕様書に変換し生成する。
　図１（ａ）に示すように、ＡＰＩ仕様書生成装置１００は、ＲＥＳＴ ＡＰＩ１０と既存機能１２間で送受信されるＡＰＩリクエスト－レスポンスをキャプチャ可能に設置される（詳細後記）。
　図１（ｂ）の符号ｄに示すように、キャプチャブロック＃１でキャプチャされたＡＰＩリクエスト－レスポンス１２６は、ＯＡＳ生成処理ブロック＃２に出力される。
　ＯＡＳ生成処理ブロック＃２は、ＯＡＳ雛形設定部１１１（後記）、挿入値ファイル設定部１１２（後記）、パラメータ設定辞書１２３（後記）を有する。
　ＯＡＳ生成処理ブロック＃２では、パラメータ設定ロジックを含むＡＰＩガイドラインファイルに従い、あらかじめ用意してある雛形ファイル１２１に挿入値ファイル１２２の参照結果とパラメータを反映する（図１（ｂ）の符号ｅ参照）。
　また、一意に特定不可であるパラメータについては、例えばＡＰＩガイドラインファイルのパラメータ設定ロジックに従い、パラメータ設定辞書１２３を参照の上、パラメータを設定する（図１（ｂ）の符号ｆ参照）。
　ＡＰＩ仕様書生成装置１００は、特定のＡＰＩ記述ルールへの準拠性も確認する。すなわち、図１（ｂ）の符号ｇに示すように、ＯＡＳ生成処理ブロック＃２で生成したＯＡＳをＯＡＳ出力ブロック＃３に出力し、特定のＡＰＩ記述ルールへの準拠性も確認する（後記）。
（実施形態）
　図２は、本発明の実施形態に係るＡＰＩ仕様書生成装置を示す構成図である。
　図２に示すように、既存ＡＰＬ１１は、ＲＥＳＴ ＡＰＩ１０およびＬ２（layer2）スイッチ１５を介してＡＰＩ提供装置（既存機能）２０に接続される。既存ＡＰＬ１１は、既存ＡＰＩ開発者１が使用するものとする。Ｌ２スイッチ１５は、パケットのＭＡＣ（Media Access Control）アドレスにより中継先を判断して中継動作を行う。
　ＡＰＩ仕様書生成装置１００は、ＲＥＳＴ ＡＰＩ１０とＡＰＩ提供装置２０間に設置される。ＡＰＩ仕様書生成装置１００は、既存ＡＰＩの仕様を自動で標準仕様の仕様書に変換し生成する。
　ＡＰＩ仕様書生成装置１００は、既存ＡＰＩ開発者２からの入力を受付けるＡＰＩリクエスト－レスポンスＩＦ部１０１と、ＡＰＩリクエスト－レスポンスキャプチャ部１０２と、ＯＡＳ作成部１１０と、ＯＡＳ雛形設定部１１１と、挿入値ファイル設定部１１２と、パラメータ設定辞書格納部１１３と、を備える。上記ＯＡＳ雛形設定部１１１、挿入値ファイル設定部１１２およびパラメータ設定辞書格納部１１３は、ＡＰＩ記述ルール作成者／システム運用者３からの入力を受付ける。
　また、ＡＰＩ仕様書生成装置１００は、ＡＰＩ記述ルール設定方式入力部１０３と、ＡＰＩ記述ルール作成者／システム運用者３からの入力を受付けるＡＰＩ記述ルール入力部１０４と、ＡＰＩ記述ルール作成者／システム運用者４からの入力を受付けるＡＰＩ記述ルール解析部１０５と、チェックポリシー設定部１０６と、既存ＡＰＩ開発者５からの入力を受付けるＡＰＩ設計エディタ部１０７と、準拠性チェック処理部１０８と、を備える。
　なお、既存ＡＰＩ開発者１、既存ＡＰＩ開発者２、および既存ＡＰＩ開発者５は、同一の開発者であってもよい。ＡＰＩ記述ルール作成者／システム運用者３およびＡＰＩ記述ルール作成者／当該システム運用者４は、同一の運用者であってもよい。
　ＡＰＩリクエスト－レスポンスＩＦ部１０１は、既存ＡＰＩ開発者２からの入力を変換してＡＰＩ提供装置２０に送信するととともに、ＡＰＩリクエスト－レスポンスキャプチャ部１０２に該当ＡＰＩリクエスト－レスポンスのデータ取込みを設定する。なお、ＡＰＩ提供装置２０は、ＡＰＩリクエスト－レスポンスＩＦ部１０１からの送信に対する応答を返す。
　なお、上記ＡＰＩリクエスト－レスポンスのデータは、具体的にはＡＰＩリクエスト－レスポンス１２６（図１３参照）の各パラメータの値（詳細後記）である。
　ＡＰＩリクエスト－レスポンスキャプチャ部１０２は、ＡＰＩリクエストとそのレスポンスであるＡＰＩリクエスト－レスポンス１２６（図１３参照）をキャプチャする。図２では、ＡＰＩリクエスト－レスポンスキャプチャ部１０２は、Ｌ２スイッチ１５により中継されたＡＰＩリクエスト－レスポンス１２６をキャプチャし、キャプチャしたＡＰＩリクエスト－レスポンス１２６をＯＡＳ作成部１１０に出力する。
　ＯＡＳ作成部１１０は、キャプチャしたＡＰＩリクエスト－レスポンス１２６（図１３参照）データと、挿入値ファイル１２２（図４参照）の参照結果とを雛形ファイル１２１（図３参照）に反映してパラメータを設定し、設定したパラメータをもとにＯＡＳ仕様書１２７（図６参照）を作成する。
　なお、ＡＰＩリクエスト－レスポンス１２６のパラメータに応じて変更する部分は、置換箇所を示す変換タグを記載する。
　また、ＯＡＳ作成部１１０は、キャプチャしたＡＰＩリクエスト－レスポンスデータと、挿入値ファイル１２２の参照結果とを雛形ファイル１２１に反映して暫定パラメータを設定するとともに、キャプチャしたＡＰＩリクエスト－レスポンスデータと、パラメータ設定辞書１２３（図５参照）を参照して、暫定パラメータをより精度の高いパラメータに設定し、設定したパラメータをもとにＯＡＳ仕様書１２７を作成する。
　ＯＡＳ作成部１１０は、ＡＰＩリクエスト－レスポンス１２６（図１３参照）のみでは一意に決められず、パラメータ設定辞書１２３の参照が必要とされる領域は、該当するＯＡＳタグ部分に辞書への参照命令を記載する。
　なお、挿入値ファイル１２２に記載するパラメータ設定ロジックの書き方によっては、ＨＴＴＰ以外のプロトコルもＯＡＳ仕様書１２７に自動反映することも可能である（後記図８参照）。
　ＯＡＳ雛形設定部１１１は、ＯＡＳ仕様書１２７（図６参照）を作成する際のＯＡＳ雛形（雛形ファイル１２１）（図３参照）をあらかじめ設定する。雛形ファイル１２１は、置換箇所を変換タグとして記載する。
　挿入値ファイル設定部１１２は、ＯＡＳ仕様書１２７（図６参照）で用いるパラメータ設定ロジックを記述する挿入値ファイル１２２（図４参照）を設定する。挿入値ファイル１２２は、雛形ファイル１２１に反映するパラメータ設定ロジックを有する。挿入値ファイル設定部１１２は、雛形ファイル１２１（図３参照）記載の変換タグに対応した挿入値ファイル１２２を設定する。
　パラメータ設定辞書格納部１１３は、一意にＯＡＳ仕様書１２７（図６参照）へ反映が難しいパラメータを登録するパラメータ設定辞書１２３（図５参照）を格納する。
　ＡＰＩ記述ルール設定方式入力部１０３は、ＡＰＩ記述ルールの記述様式を入力する。例えば、ＡＰＩ記述ルール作成者／システム運用者４がＡＰＩ記述ルールの記述様式をＡＰＩ記述ルール設定方式入力部１０３にあらかじめ入力する。
　ＡＰＩ記述ルール入力部１０４は、アプリケーションプログラミングインタフェースを設計する際のルールを記述したＡＰＩ記述ルールを入力する。
　ＡＰＩ記述ルール入力部１０４は、ＡＰＩ記述ルール作成者／システム運用者３が、アノテーションや正規表現等の一般的なプログラミング言語、または、ＡＰＩ仕様書生成装置１００が指定するＡＰＩ特有の記述様式に従って記載されたＡＰＩ記述ルールを入力するインポート（import）部である。上記ＡＰＩ記述ルールは、ＡＰＩ仕様書生成装置１００が指定する記述様式に従って記載されたSyntax的なＡＰＩ記述ルール、および、Semantic的なＡＰＩ記述ルールである。具体的には、上記Syntax的なエラーは、構文／文法的なエラーである。上記Semantic的なエラーは、ＡＰＩ仕様の設計に関する領域において、使用しているメソッドがＣＲＵＤ（Create，Read，Update，Delete）の考え方に従っているか等意味の違いや矛盾によって生じるエラーである。
　また、ＡＰＩ記述ルール入力部１０４は、ＡＰＩ記述ルール作成者／システム運用者３が、チェックポリシーを記載したソースコード等を入力する。
　ＡＰＩ記述ルール解析部１０５は、ＡＰＩ記述ルールを解析してチェックポリシーを作成する。詳細には、ＡＰＩ記述ルール解析部１０５は、ＡＰＩ記述ルール設定方式入力部１０３により事前に規定された記述様式に従い、ＡＰＩ記述ルールを解析してチェックポリシーを作成する。作成したチェックポリシーは、チェックポリシー設定部１０６に送られる。
　チェックポリシー設定部１０６は、ＡＰＩ記述ルール作成者／システム運用者４が、チェックポリシーに間違いのないことを確認する。チェックポリシーに間違いのないことが確認されると、チェックポリシー設定部１０６は、チェックポリシーを準拠性チェック処理部１０８に反映する。
　ＡＰＩ設計エディタ部１０７は、既存ＡＰＩ開発者５が、ＡＰＩ設計書を入力する。
　準拠性チェック処理部１０８は、チェックポリシーに基づいてＡＰＩ記述ルールに準拠していることをチェックする。準拠性チェック処理部１０８は、ＯＡＳ作成部１１０から送られたＯＡＳ仕様書１２７をもとに、ＡＰＩ記述ルールへの準拠性をチェックする。
　具体的には、準拠性チェック処理部１０８は、既存ＡＰＩ開発者５からＡＰＩ設計書の入力を受け付け、入力されたＡＰＩ設計書をチェックポリシーに基づいてチェックし、チェックポリシーに沿っていない非準拠箇所を既存ＡＰＩ開発者５に通知する。
　ＡＰＩ記述ルール作成者／システム運用者３は、ＡＰＩ設計エディタ部１０７を用いてＡＰＩ設計書を入力してもよいし、ＡＰＩ仕様書生成装置１００の提供するＡＰＩを用いてＡＰＩ設計書を送付してもよい。ＡＰＩ記述ルール作成者／システム運用者３がＡＰＩ設計エディタ部１０７を用いたときは、ＡＰＩ設計書の非準拠箇所をＡＰＩ設計エディタ部１０７に出力し、既存ＡＰＩ開発者５に通知する。
　なお、図２のＡＰＩリクエスト－レスポンスＩＦ部１０１およびＡＰＩリクエスト－レスポンスキャプチャ部１０２は、図１のキャプチャブロック＃１に対応する。図２のＯＡＳ作成部１１０、ＯＡＳ雛形設定部１１１、挿入値ファイル設定部１１２、およびパラメータ設定辞書格納部１１３は、図１のＯＡＳ生成処理ブロック＃２に対応する。図２のＡＰＩ記述ルール設定方式入力部１０３、ＡＰＩ記述ルール入力部１０４、ＡＰＩ記述ルール解析部１０５、チェックポリシー設定部１０６、ＡＰＩ設計エディタ部１０７、および準拠性チェック処理部１０８、図１のＯＡＳ出力ブロック＃３に対応する。
 <雛形ファイル１２１>
　図３は、ＯＡＳ雛形設定部１１１が設定する雛形ファイル１２１の一例を示す図である。
　雛形ファイル１２１は、ＡＰＩリクエスト－レスポンス１２６（図１３参照）の各パラメータの値に応じてＯＡＳ仕様書１２７（図６参照）を作成するための雛形である。雛形ファイル１２１は、置換箇所を変換タグとして記載する。
　雛形ファイル１２１には、ＡＰＩリクエスト－レスポンス１２６のパラメータに応じて変更する部分に、置換箇所を示す変換タグが記載される。図３に示す雛形ファイル１２１は、「！！」に示す置換箇所（図３の太文字参照）が変換タグとして記載される。
 <挿入値ファイル１２２>
　図４は、挿入値ファイル設定部１１２が設定する挿入値ファイル１２２の一例を示す図である。
　挿入値ファイル１２２は、雛形ファイル１２１（図３参照）に反映するパラメータ設定ロジックを有する。なお、一意に特定できないパラメータ領域は、パラメータ設定辞書１２３を参照するなどして決定する。
　図４の符号ｗに示すように、
・host.yaml
host: [Host: ]は、リクエスト－レスポンスのHost:ヘッダの内容を、そのまま反映する。
　図４の符号ｘに示すように、
・basePath.yaml
basePath: [Request URI: - Host: ]は、リクエストパラメータの各パラメータを参照してどのようにＯＡＳへ反映するかを設定する。本実施形態では、Request URLヘッダの値からHost:ヘッダの値を差し引いた値をbasePath: として設定するロジックを記載する。
　図４の符号ｙに示すように、
・type_1.yaml
 [Member Key: SELECT ParameterType FROM ParameterＤＢ WHERE [Member Key] = ParameterＤＢ.Word ]は、データ型等、ＡＰＩリクエスト－レスポンスの単純解析では、一意に特定不可なパラメータについて、パラメータ設定辞書を参照して設定する。
 <パラメータ設定辞書１２３>
　図５は、ＯＡＳ作成部１１０の動作を示す図である。ＯＡＳ作成部１１０の動作については、後記し、パラメータ設定辞書１２３の構成例について述べる。
　パラメータ設定辞書１２３は、一意にＯＡＳ仕様書１２７（図６参照）へ反映が難しいパラメータを登録する。
　図５に示すように、パラメータ設定辞書１２３は、Word(項目)に対応するType(型)、format(フォーマット)、maximum(最大値)、およびminimum(最小値)を有する。Wordは、例えば、Birthday、Telephone、Creditである。Typeは、例えば、integer(整数)である。formatは、int32(整数32bit)、int64(整数64bit)である。
　図５に示すパラメータ設定辞書１２３で、例えば、Word「Birthday」が検索されると、Type 「integer」、format「int32」、maximum「99999999」、およびminimum「00」が参照される。Word「Birthday」の場合、maximumは、yyyymmdd(西暦4桁,月2桁,日2桁)が設定され、minimumは、dd(日2桁)が設定されている。このため、minimumに「00」(2桁)より大きいパラメータは設定できない。
　同様に、Word「Telephone」が検索されると、Type 「integer」、format「int32」、maximum「－(設定なし)」、およびminimum「0000000000」(8桁)が参照される。
　ＯＡＳ作成部１１０は、パラメータ設定辞書１２３を参照することで、リクエスト－レスポンスの解析のみでは機械的に設定できないパラメータついても、高い精度で適切なパラメータを設定することが可能となる（後記）。
　以下、上述のように構成されたＡＰＩ仕様書生成装置１００のＡＰＩ仕様書生成方法について説明する。
［全体動作］
ＳＴＥＰ１
　図２の符号ｈに示すように、既存ＡＰＬ１１からＡＰＩ提供装置２０に対してＡＰＩリクエストを送信する。
ＳＴＥＰ２
　ＡＰＬリクエストがない場合、図２の符号ｉに示すように、既存ＡＰＩ開発者２は、既存ＡＰＩ１１にＡＰＩリクエストを送信するために必要な情報（ＵＲＬ，リクエストパラメータ等）を入力する。既存ＡＰＩ開発者２は、ＡＰＩリクエストに対するレスポンス結果も確認する。
ＳＴＥＰ３
　図２の符号ｊに示すように、ＡＰＩリクエスト－レスポンスキャプチャ部１０２は、Ｌ２スイッチ１５により中継されたＡＰＩリクエスト－レスポンス１２６（図１３参照）をキャプチャする。
ＳＴＥＰ４
　図２の破線矢印および符号ｋに示すように、ＡＰＩ記述ルール作成者／システム運用者３は、ＯＡＳ雛形設定部１１１の雛形ファイル１２１、挿入値ファイル設定部１１２の挿入値ファイル１２２、パラメータ設定辞書格納部１１３のパラメータ設定辞書１２３について、手動により雛形ファイル１２１、挿入値ファイル１２２、パラメータ設定辞書１２３を充実化またはカスタマイズさせる。
ＳＴＥＰ５
　図２の符号ｌに示すように、ＯＡＳ作成部１１０は、ＯＡＳ雛形設定部１１１に設定された雛形ファイル１２１（図３参照）に、ＡＰＩリクエスト－レスポンスキャプチャ部１０２でキャプチャされたＡＰＩリクエスト－レスポンス１２６のキャプチャデータと挿入値ファイル設定部１１２の参照結果とを反映させる。
ＳＴＥＰ６
　図２の符号ｍに示すように、ＯＡＳ作成部１１０は、一意にＯＡＳへ反映が難しいパラメータは、パラメータ設定辞書格納部１１３が格納するパラメータ設定辞書１２３（図５参照）を参照して、暫定的にパラメータを設定する。
ＳＴＥＰ７
　図２の符号ｎに示すように、ＡＰＩ記述ルール作成者／システム運用者３は、ＡＰＩ記述ルール入力部１０４に、アノテーションや正規表現等の一般的なプログラミング言語、または、ＡＰＩ仕様書生成装置１００が指定するＡＰＩ特有の記述様式に従って記載されたＡＰＩ記述ルールを入力する。ＡＰＩ記述ルール作成者／システム運用者３は、ＡＰＩ記述ルール設定方式入力部１０３（後記）で設定された記述様式に従ってＡＰＩ記述ルールを記載する。
　上記ＡＰＩ記述ルールは、ＡＰＩ仕様書生成装置１００が指定する記述様式に従って記載されたSyntax的なＡＰＩ記述ルール、および、Semantic的なＡＰＩ記述ルールである。具体的には、ＡＰＩ記述ルールは、ＡＰＩのリソース名、パラメータ名に使用してはいけない文字や文字列を規定したルール、およびＡＰＩで使用するメソッドの使用用途を規定したルールなどである。メソッドの使用用途は、ＲＥＳＴ ＡＰＩ１０のメソッドが限定的な特徴を活かしてルールを規定できる。
　また、ＡＰＩ記述ルール作成者／システム運用者３は、チェックポリシーを記載したソースコード等を入力する。
ＳＴＥＰ８
　ＡＰＩ記述ルール設定方式入力部１０３は、ＡＰＩ記述ルールの記述様式を入力する。このＡＰＩ記述ルールの記述様式は、例えばＡＰＩ記述ルール作成者／システム運用者４があらかじめ入力する。
ＳＴＥＰ９
　図２の符号ｏに示すように、ＡＰＩ記述ルール解析部１０５は、ＡＰＩ記述ルール設定方式入力部１０３により事前に規定された記述様式に従い、ＡＰＩ記述ルールを解析してチェックポリシーを決定する。決定されたチェックポリシーは、チェックポリシー設定部１０６に送られる。
ＳＴＥＰ１０
　図２の符号ｐに示すように、ＡＰＩ記述ルール作成者／システム運用者４は、チェックポリシー設定部１０６で、チェックポリシーに間違いのないことを確認する。チェックポリシーに間違いのないことが確認されると、チェックポリシー設定部１０６は、チェックポリシーを準拠性チェック処理部１０８に反映する（図２の符号ｑ参照）。
ＳＴＥＰ１１
　一方、図２の符号ｒに示すように、ＯＡＳ作成部１１０は、作成したＯＡＳをＡＰＩ設計エディタ部１０７へ入力する。ＡＰＩ設計エディタ部１０７は、ＯＡＳとして作成された内容を表示する。
ＳＴＥＰ１２
　図２の符号ｓに示すように、ＡＰＩ設計エディタ部１０７は、ＯＡＳ作成部１１０により作成されたＯＡＳを表示させ、既存ＡＰＩ開発者５によるＡＰＩ設計書の設計および記載を支援する。
ＳＴＥＰ１２
　図２の符号ｔに示すように、準拠性チェック処理部１０８は、既存ＡＰＩ開発者５からＡＰＩ設計書（ＯＡＳ）の入力を受け付け、入力されたＡＰＩ設計書（ＯＡＳ）をチェックポリシーに基づいてチェックし、チェックポリシーに沿っていない非準拠箇所を既存ＡＰＩ開発者５に通知する（図２の符号ｕ参照）。既存ＡＰＩ開発者５は、ＡＰＩ設計エディタ部１０７を用いてＡＰＩ設計書（ＯＡＳ）を入力する。
　特に、図２の符号ｖに示すように、ＡＰＩ設計エディタ部１０７を経由して、準拠性チェック処理部１０８にＯＡＳを送ることで、準拠性チェック処理部１０８は、特定のＡＰＩ記述ルールへの準拠性チェックも確認可能である。なお、特定のＡＰＩ記述ルールは、ＡＰＩ記述ルール設定方式入力部１０３で入力されているＡＰＩ記述ルールの記述様式では準拠性チェックできないものを含む。
　準拠性チェック処理部１０８は、既存ＡＰＩ開発者５に特定のＡＰＩ記述ルールに準拠した設計内容を提案する（図２の符号ｕ参照）。
［ＯＡＳ作成部１１０動作］
　図５を参照してＯＡＳ作成部１１０の動作を説明する。
　ＯＡＳ作成部１１０（図２参照）は、ＡＰＩリクエスト－レスポンスキャプチャ部１０２（図２参照）でキャプチャされたＡＰＩリクエスト－レスポンス１２６のデータをパラメータ設定ロジックに従い、挿入値ファイル１２２へ反映させる。
　図５に示す挿入値ファイル１２２において、
・host.yaml「host:」「basePath:」は、パラメータ設定ロジックに設定されている。このため、図５の符号ｚに示すように、・host.yamlは、ＡＰＩリクエスト１２４（図１３参照）の host: petstore-api.herokuapp.comそのままとなる。同様に、・basePath.yamlは、basePath: /Petとなる。
　ＯＡＳ作成部１１０は、キャプチャしたＡＰＩリクエスト－レスポンス１２６のデータと、挿入値ファイル１２２の参照結果とを雛形ファイル１２１に反映して暫定パラメータを設定する。
　一方、「・name_1.yaml」「・type_1.yaml」「・format_1.yaml」は、パラメータ設定ロジックに設定されていない。このため、図５の符号ａ１に示すように、・host.yamlは、ＡＰＩリクエスト－レスポンスの解析のみで機械的に設定できないパラメータ（一意に特定不可であるパラメータ）である。
　この場合は、図５の符号ｂ１に示すように、パラメータ設定辞書１２３を参照して、「・name_1.yaml」「・type_1.yaml」「・format_1.yaml」に対して各パラメータを設定し、挿入値ファイル１２２に設計を反映する。
　上述したように、図５に示すパラメータ設定辞書１２３は、Wordに対応するType、format、maximum、およびminimumを有する。図５の符号ｂ１に示すように、Word「Birthday」が検索されると、Type 「integer」、format「int32」、maximum「99999999」、およびminimum「00」が参照され、挿入値ファイル１２２に設定される。すなわち、
・name_1.yaml
 birthday:
・type_1.yaml
 type: integer
・format_1.yaml
 format: int32
が挿入値ファイル１２２に設定される。
　ＯＡＳ作成部１１０は、キャプチャしたＡＰＩリクエスト－レスポンス１２６のデータと、パラメータ設定辞書１２３を参照して、暫定パラメータをより精度の高いパラメータに設定する。すなわち、一意にＯＡＳへ反映が難しいパラメータは、パラメータ設定辞書１２３を参照して、より精度の高いパラメータを設定する。
　図６は、図５のＯＡＳ作成部１１０の動作により作成されたＯＡＳ仕様書１２７を示す図である。
　図６に示すＯＡＳ仕様書１２７は、雛形ファイル１２１（図３参照）に挿入値ファイル１２２（図５参照）を挿入済のファイルを示す。
　図６中の太文字は、ＡＰＩリクエスト－レスポンス１２６のキャプチャデータとパラメータ設定辞書１２３を参照し、雛形ファイル１２１（図３参照）へ設計を反映した箇所である。
　例えば、図６に示すＯＡＳ仕様書１２７は、雛形ファイル１２１（図３参照）をもとに、
swagger: '2.0'
info:
  version: 1.0.0
  title: hogehoge
description: |
を記述し、この記述に続いて、図５に示す挿入値ファイル１２２から下記パラメータを挿入する。
host: petstore-api.herokuapp.com
basePath: /pet
schemes:
  - http
consumes:
  - application/json
produces:
  - application/json
paths:
  /:
　続いて、図５に示す挿入値ファイル１２２から下記パラメータを挿入する。
    post:
      parameters:
　雛形ファイル１２１（図３参照）をもとに、
        － name: A
を記述し、この記述に続いて、図５に示す挿入値ファイル１２２から下記パラメータを挿入する。
          in: body
　雛形ファイル１２１（図３参照）をもとに、
          description: hogehogeschema:
を記述し、この記述に続いて、図５に示す挿入値ファイル１２２から下記パラメータを挿入する。
            $ref: '#／definitions／A'
　雛形ファイル１２１（図３参照）をもとに、
          required: true
を記述し、この記述に続いて、図５に示す挿入値ファイル１２２から下記パラメータを挿入する。
      responses:
        200:
　雛形ファイル１２１（図３参照）をもとに、
          description: hogehoge
を記述する。
　以上で、「post:」の記述とその挿入値ファイル１２２からのパラメータ挿入を終え、「name: A」についての定義を記述する。すなわち、
　雛形ファイル１２１（図３参照）をもとに、
definitions:
  A:
を記述し、この記述に続いて、図５に示す挿入値ファイル１２２から下記パラメータを挿入する。
    type: object
　続いて、雛形ファイル１２１（図３参照）をもとに、
    properties:
を記述し、この記述に続いて、図５に示す挿入値ファイル１２２から下記パラメータを挿入する。
      name:
        type: string
      birthday:
        type: integer
        format: int32
　上記パラメータは、一意にＯＡＳへ反映が難しいパラメータであり、パラメータ設定辞書１２３を参照して設定される。
　以上、ＨＴＴＰ形式のＲＥＳＴ ＡＰＩを用いたＯＡＳ作成部１１０の動作について説明した。
［変形例］
　次に、変形例として、ＳＩＰ（Session Initiation Protocol）をＯＡＳ変換ロジックに変える場合について説明する。
 <雛形ファイル１２１Ａ>
　図７は、ＳＩＰをＨＴＴＰ形式のＲＥＳＴ ＡＰＩに変換する場合、ＯＡＳ雛形設定部１１１が設定する雛形ファイル１２１Ａの一例を示す図である。図３の雛形ファイル１２１と同一部分には、同一パラメータを付している。
　雛形ファイル１２１Ａは、ＡＰＩリクエスト－レスポンス１２６（図１３参照）の各パラメータの値に応じてＯＡＳ仕様書を作成するための雛形である。
　雛形ファイル１２１Ａには、ＡＰＩリクエスト－レスポンス１２６のパラメータに応じて変更する部分に、置換箇所を示す変換タグが記載される。
　ＯＡＳ作成部１１０（図５参照）は、雛形ファイル１２１Ａ記載の変換タグに対応した挿入値ファイル１２２Ａ（図８参照）を設定する。
　図７に示す雛形ファイル１２１Ａは、
　前記図３に示す雛形ファイル１２１の下記パラメータ
    properties:
      ！！Conversion name_1:
        ！！Conversion type_1:
        ！！Conversion format_1
      ！！Conversion name_2:
        ！！Conversion type_2:
        ！！Conversion format_2:
が、下記パラメータ
    properties:
      from
        ！！Conversion type_1:
        ！！Conversion format_1
      to
        ！！Conversion type_2:
        ！！Conversion format_2:
に置き換えられている。
 <挿入値ファイル１２２Ａ>
　図８は、挿入値ファイル設定部１１２が設定する挿入値ファイル１２２Ａの一例を示す図である。
　挿入値ファイル１２２Ａは、雛形ファイル１２１Ａ（図７参照）に反映するパラメータロジックを有するファイルである。なお、一意に特定できないパラメータ領域は、パラメータ設定辞書を参照するなどして決定する。
　図８に示す挿入値ファイル１２２Ａは、
・host.yaml
host: [REGISTER sip: ]
・method.yaml
－ [REGESTER: post]
－ [INVITE: get]
・type_1.yaml
[To: ]
を有する。
　図８の符号ｃ１に示すように、
・host.yaml
host: [REGISTER sip: ]は、網内プロキシに登録要求をするREGESTERメソッドによるリクエストのSIP URIをＨＴＴＰのhost部とする場合の例である。
　図８の符号ｄ１に示すように、
・method.yaml
－ [REGESTER: post]
－ [INVITE: getは、SIP REGESTERをＨＴＴＰのPOSTメソッド、SIP INVITEをGETメソッドとする場合の例である。
　図８の符号ｅ１に示すように、
・type_1.yaml
[To: ]は、SIP INVITEのTo:ヘッダの値を反映する場合の例である。
　以上、ＳＩＰをＨＴＴＰ形式のＲＥＳＴ ＡＰＩに変換する場合、ＳＩＰリクエスト－レスポンスの値を基に、ＨＴＴＰプロトコルへ変換するロジックを反映する。これにより、ＯＡＳ形式の仕様書を自動生成することが可能になる。
［構文的記述ルールの規定例］
　次に、構文的記述ルールの規定例について説明する。
　図９は、ＡＰＩ仕様書生成装置１００が規定する注釈様式に従って、構文的記述ルールを記載した例を示す図である。
　図９の例では、ＡＰＩのリソース名、パラメータ名に、アプリが動作する上でバグの原因となるおそれのある文字「％」，「：」，「￥」，「￥￥」, 「＼（バックスラッシュ）」の使用を禁止するルールが記載されている。
　具体的には、図９の符号ｆ１に示すように、“@NGcheck\Resource”は、ＡＰＩ仕様書生成装置１００が規定した記述様式であり、ＡＰＩ設計書内の各ＡＰＩのリソース名内部で特定の記述等がされた場合にエラーを出力するルール（ポリシー）である。また、図９の符号ｇ１に示すように、“@NGcheck\Parameters”は、各ＡＰＩのパラメータ名に特定の文字、文字列が存在する場合にエラー情報を出力するルール（ポリシー）である。また、図９の符号ｈ１に示すように、使用してはいけない文字、文字列が正規表現等で記述されている。
　このように、ＡＰＩのリソース名、パラメータ名に、アプリ動作する上でバグの原因となるおそれのある「%」, 「:」, 「\」, 「＼」の使用を禁止する場合は、ＡＰＩ仕様書生成装置１００が指定する記述様式を用いて正規表現等を活用して記述したファイルをＡＰＩ記述ルール入力部１０４（図２参照）にインポートする（図９の符号ｉ１参照）。
　準拠性チェック処理部１０８（図２参照）は、記述された内容に従って、準拠性チェックポリシーを規定する。
　図９の符号ｊ１に示すように、ＡＰＩ設計エディタ部１０７（図２参照）は、記載されたＡＰＩ仕様を、事前に規定されたチェックポリシーに従って準拠性確認をし、その結果を既存ＡＰＩ開発者５に通知する。通知形式は、ＡＰＩ設計エディタ部１０７がリアルタイムに通知を行う。
［メソッド使用ルールの規定例］
　次に、メソッド使用ルールの規定例について説明する。
　図１０は、ＡＰＩ記述ルールを表にして示す図である。図１０に示す表は、ＡＰＩ記述ルールとして各メソッドの使用用途を規定する。
　図１０の表に示すように、ＣＲＵＤ（Create，Read，Update，Delete）毎に、メソッド名（ＰＯＳＴ，ＧＥＴ，ＰＵＴ，ＤＥＬＥＴＥ）と、対応する用途を規定する。
　ＡＰＩ記述ルールとして各メソッドの使用用途を図１０の表に規定したと仮定する。例えば、リソースを新規に作成／更新／削除するようなＡＰＩにもかかわらず、「ＧＥＴ」を用いているかを確認する。図１０の表で規定したルールに反して用途に合っていないメソッドが使われている場合にエラーを出力する。
　図１１は、ＡＰＩ仕様書生成装置１００が規定する記述様式に従って、メソッド使用ルールを記載した例を示す図である。
　図１１の符号ｋ１に示すように、“@NGcheck\Api”は、一つのエンドポイント毎のＡＰＩに関する設計（概要やメソッド）において、特定の条件に当てはまる記述が存在する場合にエラーを出力するルール（ポリシー）である。図１１の符号ｌ１に示すように、ＡＰＩ仕様書生成装置１００が規定した記述様式でエラーを出力するポリシーを記載する。例えば、ＡＰＩの説明文（description部）に「更新」、「create」、「追加」、「add」、「削除」、「delete」という記載があり、かつ、ＧＥＴメソッドを使用している場合、エラーを出力する。より具体的には、ＡＰＩ設計書において、ある行にＧＥＴメソッドを使用することが記載されており、その後の行のＡＰＩの説明文に“Create”の記述がある場合を想定する。このＡＰＩ設計書は、リソースを新規に作成するＡＰＩにもかかわらずＧＥＴを用いている。したがって、このＡＰＩ設計書をＡＰＩ仕様書生成装置１００に入力した場合、用途に合っていないメソッドが使われている旨のエラー情報が出力される。
　ＡＰＩ仕様書生成装置１００が規定する記述様式に沿った設計、または、一般的なプログラミング言語で、エラー検出のロジックを組むことで、ルール違反したメソッドの使用をチェックすることが可能になる。
　以上説明したように、本実施形態のＡＰＩ仕様書生成装置１００（図１参照）は、ＯＡＳ仕様書１２７を作成する際の雛形ファイル１２１をあらかじめ設定するＯＡＳ雛形設定部１１１と、ＯＡＳ仕様書１２７で用いるパラメータ設定ロジックを記述する挿入値ファイル１２２を設定する挿入値ファイル設定部１１２と、ＡＰＩリクエストとそのレスポンスをキャプチャするＡＰＩリクエスト－レスポンスキャプチャ部１０２と、キャプチャしたＡＰＩリクエスト－レスポンスデータと、挿入値ファイル１２２の参照結果とを雛形ファイル１２１に反映してパラメータを設定し、設定したパラメータをもとにＯＡＳ仕様書１２７を作成するＯＡＳ作成部１１０と、を備える。
　この構成により、ＡＰＩリクエスト－レスポンス１２６をもとに低コストでデータ型や値の範囲まで反映するＯＡＳ仕様書１２７を作成できる。また、各種プロトコルの値から、ＯＡＳにパラメータをどのように設定するかを記述するパラメータ設定ロジックも、システム運用者にてカスタマイズ可能である。さらに、独自パラメータやＨＴＴＰ以外のプロトコルもＯＡＳ仕様書の対象にすることができる。
　本実施形態では、ＡＰＩ仕様書生成装置１００は、一意にＯＡＳ仕様書１２７へ反映が難しいパラメータを登録するパラメータ設定辞書１２３を格納するパラメータ設定辞書格納部１１３を備え、ＯＡＳ作成部１１０は、キャプチャしたＡＰＩリクエスト－レスポンス１２６のデータと、挿入値ファイル１２２の参照結果とを雛形ファイル１２１に反映して暫定パラメータを設定するとともに、キャプチャしたＡＰＩリクエスト－レスポンス１２６のデータと、パラメータ設定辞書を参照して、暫定パラメータをより精度の高いパラメータに設定し、設定したパラメータをもとにＯＡＳ仕様書１２７を作成する。
　このようにすることで、ＡＰＩリクエスト－レスポンス１２６とＡＰＩパラメータ設定辞書１２３を参照して、一意に特定不可であるパラメータも高精度で設計可能となる。このため、ＯＡＳ仕様書１２７の作成および修正稼働を削減することができる。
　また、上記実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。この他、上述文書中や図面中に示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
　また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。
　また、上記の各構成、機能、処理部、処理手段等は、それらの一部または全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行するためのソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、または、ＩＣ（Integrated Circuit）カード、ＳＤ（Secure Digital）カード、光ディスク等の記録媒体に保持することができる。また、本明細書において、時系列的な処理を記述する処理ステップは、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）をも含むものである。
　１０　ＲＥＳＴ ＡＰＩ
　１１　既存ＡＰＬ
　１５　Ｌ２スイッチ
　２０　ＡＰＩ提供装置（既存機能）
　１００　ＡＰＩ仕様書生成装置
　１０１　ＡＰＩリクエスト－レスポンスＩＦ部
　１０２　ＡＰＩリクエスト－レスポンスキャプチャ部（ＡＰＩリクエスト－レスポンスキャプチャ手段）
　１０３　ＡＰＩ記述ルール設定方式入力部
　１０４　ＡＰＩ記述ルール入力部
　１０５　ＡＰＩ記述ルール解析部
　１０６　チェックポリシー設定部
　１０７　ＡＰＩ設計エディタ部
　１０８　準拠性チェック処理部
　１１０　ＯＡＳ作成部（ＯＡＳ作成手段）
　１１１　ＯＡＳ雛形設定部（ＯＡＳ雛形設定手段）
　１１２　挿入値ファイル設定部（挿入値ファイル設定手段）
　１１３　パラメータ設定辞書格納部
　１２１，１２１Ａ　雛形ファイル
　１２２，１２２Ａ　挿入値ファイル
　１２３　パラメータ設定辞書
　１２４　ＡＰＩリクエスト
　１２５　ＡＰＩレスポンス
　１２６　ＡＰＩリクエスト－レスポンス
　１２７　ＯＡＳ仕様書

Claims (5)

  1. 　既存ＡＰＩ（Application Program Interface）の仕様を変換して標準仕様のＯＡＳ（Open API spec）仕様書を生成するＡＰＩ仕様書生成装置であって、
    　前記ＯＡＳ仕様書を作成する際の雛形ファイルをあらかじめ設定するＯＡＳ雛形設定部と、
    　前記ＯＡＳ仕様書で用いるパラメータ設定ロジックを記述する挿入値ファイルを設定する挿入値ファイル設定部と、
    　ＡＰＩリクエストとそのレスポンスをキャプチャするＡＰＩリクエスト－レスポンスキャプチャ部と、
    　キャプチャしたＡＰＩリクエスト－レスポンスデータと、前記挿入値ファイルの参照結果とを前記雛形ファイルに反映してパラメータを設定し、設定した前記パラメータをもとに前記ＯＡＳ仕様書を作成するＯＡＳ作成部と、を備える
    　ことを特徴とするＡＰＩ仕様書生成装置。
  2. 　一意にＯＡＳ仕様書へパラメータを登録するパラメータ設定辞書を格納するパラメータ設定辞書格納部をさらに備え、
    　前記ＯＡＳ作成部は、
    　キャプチャしたＡＰＩリクエスト－レスポンスデータと、前記挿入値ファイルの参照結果とを前記雛形ファイルに反映して暫定パラメータを設定するとともに、
    　キャプチャしたＡＰＩリクエスト－レスポンスデータと、前記パラメータ設定辞書を参照して、前記暫定パラメータを、当該暫定パラメータよりも精度の高いパラメータに設定し、設定した前記パラメータをもとに前記ＯＡＳ仕様書を作成する
    　ことを特徴とする請求項１に記載のＡＰＩ仕様書生成装置。
  3. 　アプリケーションプログラミングインタフェースを設計する際のルールを記述したＡＰＩ記述ルールを入力するＡＰＩ記述ルール入力部と、
    　前記ＡＰＩ記述ルールを解析してチェックポリシーを作成するＡＰＩ記述ルール解析部と、
    　前記チェックポリシーに基づいて前記ＡＰＩ記述ルールに準拠していることをチェックする準拠性チェック処理部と、をさらに備え、
    　前記ＯＡＳ作成部は、
    　作成した前記ＯＡＳ仕様書を前記準拠性チェック処理部に送り、
    　前記準拠性チェック処理部は、
    　前記ＯＡＳ作成部から送られた前記ＯＡＳ仕様書をもとに、前記ＡＰＩ記述ルールへの準拠性をチェックする
    　ことを特徴とする請求項１に記載のＡＰＩ仕様書生成装置。
  4. 　既存ＡＰＩの仕様を変換して標準仕様のＯＡＳ仕様書を生成するＡＰＩ仕様書生成装置が、
    　前記ＯＡＳ仕様書を作成する際の雛形ファイルをあらかじめ設定するステップと、
    　前記ＯＡＳ仕様書で用いるパラメータ設定ロジックを記述する挿入値ファイルを設定するステップと、
    　ＡＰＩリクエストとそのレスポンスをキャプチャするステップと、
    　キャプチャしたＡＰＩリクエスト－レスポンスデータと、前記挿入値ファイルの参照結果とを前記雛形ファイルに反映してパラメータを設定し、設定した前記パラメータをもとに前記ＯＡＳ仕様書を作成するステップと、を実行する
    　ことを特徴とするＡＰＩ仕様書生成方法。
  5. 　既存ＡＰＩの仕様を変換して標準仕様のＯＡＳ仕様書を生成するＡＰＩ仕様書生成装置としてのコンピュータを、
    　前記ＯＡＳ仕様書を作成する際の雛形ファイルをあらかじめ設定するＯＡＳ雛形設定手段、
    　前記ＯＡＳ仕様書で用いるパラメータ設定ロジックを記述する挿入値ファイルを設定する挿入値ファイル設定手段、
    　ＡＰＩリクエストとそのレスポンスをキャプチャするＡＰＩリクエスト－レスポンスキャプチャ手段、
    　キャプチャしたＡＰＩリクエスト－レスポンスデータと、前記挿入値ファイルの参照結果とを前記雛形ファイルに反映してパラメータを設定し、設定した前記パラメータをもとに前記ＯＡＳ仕様書を作成するＯＡＳ作成手段、
    　として機能させるためのプログラム。
PCT/JP2019/030228 2018-08-07 2019-08-01 Ａｐｉ仕様書生成装置、ａｐｉ仕様書生成方法、およびプログラム WO2020031845A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2018148615A JP2020024567A (ja) 2018-08-07 2018-08-07 Ａｐｉ仕様書生成装置、ａｐｉ仕様書生成方法、およびプログラム
JP2018-148615 2018-08-07

Publications (1)

Publication Number Publication Date
WO2020031845A1 true WO2020031845A1 (ja) 2020-02-13

Family

ID=69414186

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2019/030228 WO2020031845A1 (ja) 2018-08-07 2019-08-01 Ａｐｉ仕様書生成装置、ａｐｉ仕様書生成方法、およびプログラム

Country Status (2)

Country Link
JP (1) JP2020024567A (ja)
WO (1) WO2020031845A1 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10747505B1 (en) * 2019-05-17 2020-08-18 Google Llc API specification generation
CN111399900B (zh) * 2020-03-10 2023-04-07 山东汇贸电子口岸有限公司 一种基于python与正则表达式的API文档自动生成方法及系统

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170012838A1 (en) * 2015-07-09 2017-01-12 Microsoft Technology Licensing, Llc Automatically generating service documentation based on actual usage
US9936005B1 (en) * 2017-07-28 2018-04-03 Kong Inc. Systems and methods for distributed API gateways
JP2018055625A (ja) * 2016-09-30 2018-04-05 富士通株式会社 情報処理装置、仕様書作成方法及び仕様書作成プログラム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170012838A1 (en) * 2015-07-09 2017-01-12 Microsoft Technology Licensing, Llc Automatically generating service documentation based on actual usage
JP2018055625A (ja) * 2016-09-30 2018-04-05 富士通株式会社 情報処理装置、仕様書作成方法及び仕様書作成プログラム
US9936005B1 (en) * 2017-07-28 2018-04-03 Kong Inc. Systems and methods for distributed API gateways

Also Published As

Publication number Publication date
JP2020024567A (ja) 2020-02-13

Similar Documents

Publication Publication Date Title
CN100399323C (zh) 用于检验扩展标记语言文件的有效性的装置和方法
US10452407B2 (en) Adapter configuration
US20070067512A1 (en) Method, system and software arrangement for processing a device support file for a field device
US8561088B2 (en) Registering network applications with an API framework
US20070198457A1 (en) Accessing and manipulating data in a data flow graph
US11842231B2 (en) Cloud-based API metadata management method and system for integrated API management
WO2020031845A1 (ja) Ａｐｉ仕様書生成装置、ａｐｉ仕様書生成方法、およびプログラム
CN105138454A (zh) 一种针对b/s架构安全软件的自动化测试方法
US7237222B1 (en) Protocol for controlling an execution process on a destination computer from a source computer
CN117493158A (zh) 测试方法及其装置、电子设备、存储介质
Bojinov RESTful Web API Design with Node. js 10: Learn to create robust RESTful web services with Node. js, MongoDB, and Express. js
US10606569B2 (en) Declarative configuration elements
KR100762712B1 (ko) 규칙기반의 전자문서 변환방법 및 그 시스템
Bojinov RESTful Web API Design with Node. js
US9135267B2 (en) Method for adding real time collaboration to existing data structure
Jaekel et al. Ensure OPC-UA interfaces for digital plug-and-produce
CN111294232B (zh) 用于多文档编辑器的计算机系统
US11144287B2 (en) Compile time validation of programming code
Troelsen et al. RESTful Services with ASP. NET Core
US8825686B2 (en) Expression evaluation over multiple data models
US20240256435A1 (en) Method and system for testing compatibility of api specifications
CN110633158B (zh) 在过程建模中实现同步可编辑信号的方法、系统和介质
CN114500679B (zh) can协议转换方法、装置、电子设备和存储介质
Kelly Aggregating Private and Public Web Archives Using the Mementity Framework
KR100901702B1 (ko) Ｏｃｌ 기반의 프로바이더 검증 장치 및 방법

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19847681

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19847681

Country of ref document: EP

Kind code of ref document: A1