JP6721548B2 - Design confirmation device and design confirmation method - Google Patents

Description

The present invention relates to a technique of defining an API design rule and confirming whether an API design document complies with the rule.

In recent years, various network services have been provided in the form of application programming interfaces (APIs).

The techniques of Non-Patent Documents 1 and 2 are known as techniques related to API design. Non-Patent Document 1 is a technology that supports the creation of an API design document according to a predetermined specification.

JP, 2016-151881, A JP, 2016-151780, A

"Swagger Editor", [online], SmartBear Software, [June 21, 2017 search], Internet <URL: http://swagger.io/swagger-editor/> "API Blueprint", [online], api blueprint, [June 21, 2017 search], Internet <URL: https://apiblueprint.org/> Kikuma, 3 others, “Study on automation of test item creation from required specifications in large-scale communication software development”, 11th Network Software Workshop, IEICE, 2016

The technique of Non-Patent Document 1 can detect a syntax/grammatical error, but cannot set/customize the API design rule independently. Further, it is impossible to detect an error caused by a difference in usage of the method or a contradiction, such as whether the method used in the API follows the concept of CRUD (Create, Read, Update, Delete). Although Non-Patent Document 3 is a technique for analyzing a specification, there is no mention of analysis that makes use of the feature that methods that can be used in the REST API area are limited.

The present invention has been made in view of the above, and an object thereof is to make it possible to customize API design rules and reduce the burden of confirming conformity to the design rules.

A design confirmation apparatus according to a first aspect of the present invention is a design rule input means for inputting a design rule describing a rule for designing an application programming interface, and a design rule analysis for analyzing the design rule to create a check policy. Means, and a design document checking unit for inputting a design document of an application programming interface and determining whether or not the design rule is complied with based on the check policy.

A design confirmation method according to a second aspect of the present invention is a design confirmation method executed by a design confirmation device, which comprises a step of inputting a design rule describing a rule when designing an application programming interface, and the design rule. It is characterized by including a step of analyzing and creating a check policy, and a step of inputting a design document of an application programming interface and judging whether or not the design rule is complied with based on the check policy. ..

According to the present invention, the API design rule can be customized, and the burden of confirming the conformity to the design rule can be reduced.

It is a functional block diagram which shows the structure of the design confirmation apparatus 1 of this embodiment. It is a figure which shows the example of API description rule. It is a figure which shows the example of API design document.

Embodiments of the present invention will be described below with reference to the drawings.

FIG. 1 is a functional block diagram showing the configuration of the design confirmation device 1 of this embodiment. The design confirmation apparatus 1 shown in FIG. 1 includes an API description rule input unit 11, an API description rule analysis unit 12, a check policy setting unit 13, a compliance check processing unit 14, an API design editor unit 15, and an API description rule setting method input. The unit 16 is provided. Each unit included in the design confirmation device 1 may be configured by a computer including an arithmetic processing device, a storage device, and the like, and the processing of each unit may be executed by a program. This program is stored in the storage device included in the design confirmation apparatus 1, and can be recorded in a recording medium such as a magnetic disk, an optical disk, a semiconductor memory, or provided through a network. Hereinafter, each part of the design confirmation device 1 will be described.

The API description rule input unit 11 inputs an API description rule described according to a general programming language such as annotations and regular expressions, or a description format specific to the API specified by the design confirmation device 1. The input API description rule is sent to the API description rule analysis unit 12. The API description rule is, for example, a rule that defines a character or a character string that should not be used for a resource name and a parameter name of the API, a rule that defines a usage of a method used in the API, and the like. Regarding the usage of the method, rules can be defined by taking advantage of the limited characteristics of the REST API method.

The API description rule analysis unit 12 analyzes the API description rule and determines a check policy in accordance with the description format defined in advance by the system operator. The determined check policy is sent to the check policy setting unit 13.

In the check policy setting unit 13, the system operator confirms that the check policy is correct. If it is confirmed that the check policy is correct, the check policy setting unit 13 reflects the check policy in the compliance check processing unit 14.

The compliance check processing unit 14 receives an API design document input from the API designer, checks the input API design document based on a check policy, and notifies the API designer of a non-compliant portion that does not comply with the check policy. To do. The API designer may use the API design editor unit 15 included in the design confirmation device 1 to input the API design document, or may send the API design document using the API provided by the design confirmation device 1. .. When the API designer uses the API design editor unit 15, the non-compliant portion of the API design document is output to the API design editor unit 15 to notify the API designer.

The API description rule setting method input unit 16 inputs the description form of the API description rule from the system operator. The API description rule creator writes the API description rule according to the description format set by the API description rule setting method input unit 16.

By providing the functions of the API description rule input unit 11 and the compliance check processing unit 14 as APIs and using them as a common system by multiple businesses, it is possible to integrate check policies according to the API description rules of multiple businesses. Becomes

Next, an example of the API description rule will be described.

FIG. 2 is a diagram showing an example of the API description rule. The API description rule in the figure includes an example of defining a syntactic description rule and an example of defining a method use rule.

First, a definition example of the syntactic description rule will be described. In the example of FIG. 2, characters "%", ":", "\", "\\" (backslash) that may cause a bug in the operation of the application are added to the API resource name and parameter name. The rules that prohibit the use of are described. Specifically, “@NGcheck\Resource” on the second line of FIG. 2 is a description format set in the design confirmation device 1, and is a character or character string specific to the resource name of each API in the API design document. This is a rule that outputs error information when exists. In addition, “@NGcheck\Parameters” on the fourth line is a rule that outputs error information when a specific character or character string exists in the parameter name of each API. Characters and character strings that should not be used are described in regular expressions on the third and fifth lines.

Next, a stipulated example of the method use rule will be described. It is assumed that the usage of each method is defined as the API description rule as shown in Table 1.

In the present embodiment, error information is output when a method that does not suit the purpose is used, contrary to the rules defined in Table 1. In the example of FIG. 2, “@NGcheck\Api” on the 8th line outputs error information when there is a description that meets specific conditions in the design (outline or method) related to the API for each endpoint. It is a rule. The ninth line is a policy for outputting error information. In the example of FIG. 2, any description of “update”, “create”, “add”, “add”, “delete”, and “delete” is described in the API description (description section) described in the API design document. Yes, output error information when using the GET method.

FIG. 3 shows an example of the API design document. In the API shown in FIG. 3, it is described that the GET method is used on the third line, and “Create” is described in the API description column on the seventh line. In other words, this API uses GET despite the API for newly creating a resource. Therefore, when this API design document is input to the design confirmation device 1, error information indicating that a method that does not suit the purpose is used is output.

As described above, according to the present embodiment, the design confirmation device 1 determines the rule that defines the characters and character strings that should not be used in the API resource name and the parameter name and the usage of the method used in the API. An API description rule input unit 11 for inputting an API description rule describing a defined rule, an API description rule analysis unit 12 for analyzing the API description rule and determining a check policy, and an API designer's input of an API design document. By having the compliance check processing unit 14 that receives and checks the input API design document based on the check policy, it is possible to set/customize the API design rule and reduce the burden of confirming the compliance with the design rule.

According to the present embodiment, the functions of the API description rule input unit 11 and the compliance check processing unit 14 are provided as APIs and used as a common system by a plurality of businesses, so that a check according to the API description rules of a plurality of businesses is performed. Policy integration is possible.

DESCRIPTION OF SYMBOLS 1... Design confirmation device 11... API description rule input unit 12... API description rule analysis unit 13... Check policy setting unit 14... Compliance check processing unit 15... API design editor unit 16... API description rule setting method input unit

Claims (8)

Design rule input means for inputting design rules describing rules for designing an application programming interface,
Design rule analysis means for analyzing the design rule to create a check policy,
Design document check means for inputting a design document of an application programming interface and determining whether or not the design rule is complied with based on the check policy,
A design confirmation device having: The design rule input means inputs a plurality of the design rules,
The design confirmation apparatus according to claim 1, wherein the design rule analysis unit integrates analysis results of the plurality of design rules to create the check policy. The design confirmation apparatus according to claim 1, wherein the design rule defines prohibited characters and character strings. 4. The design confirmation device according to claim 1, wherein the design rule defines a usage of a method used by the application programming interface. A design confirmation method executed by a design confirmation device, comprising:
A step of inputting a design rule describing a rule for designing an application programming interface,
Creating a check policy by analyzing the design rules,
Inputting a design document of the application programming interface and determining whether or not the design rule is complied with based on the check policy;
A method for confirming design, comprising: In the step of inputting the design rule, input a plurality of the design rules,
The design confirmation method according to claim 5, wherein, in the step of creating the check policy, the analysis results of the plurality of design rules are integrated to create the check policy. 7. The design confirmation method according to claim 5, wherein the design rule defines prohibited characters and character strings. 8. The design confirmation method according to claim 5, wherein the design rule defines a method used by the application programming interface.

Images