Specification verification method, system, device and storage medium

Abstract

The embodiment of the present application provides a specification verification method, system, device and storage medium. The method comprises the following steps: when a save request sent by a design terminal for description information of an application programming interface is received, pre-save rule verification is performed on the description information; the description information is edited by a design user on the design terminal; when the pre-save rule verification is passed, the description information is saved; after the description information is saved, when a release request sent by the design terminal for the description information is received, pre-release rule verification is performed on the description information, so as to control the release process of the application programming interface; wherein the pre-save reference rule for the pre-save rule verification belongs to a mandatory rule; and the pre-release reference rule for the pre-release rule verification belongs to a flexible rule. The detection scheme provided by the embodiment of the present application can improve the rationality of specification verification, and further reduce the artificial input cost.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a standard verification method, system, device and storage medium. Background Technology

[0002] With the development of cloud computing and the continuous evolution of the API (Application Programming Interface) ecosystem, the number and usage of APIs have exploded within organizations, and the need to integrate product capabilities through APIs has become commonplace. Developers utilize APIs by consulting API documentation on product websites, calling them through SDKs (Software Development Kits), and using API-related tools to troubleshoot issues. The presentation of APIs represents the face of the product, and the smoothness with which users interact with APIs reflects the product's capabilities.

[0003] The sheer number and scale of customers relying on APIs underscores their critical importance. API failures can have far-reaching and potentially irreversible impacts. To minimize API failures, API designers must adhere to specifications. Furthermore, API designs must undergo specification validation to identify and resolve issues before release. Summary of the Invention

[0004] This application provides a standard verification method, system, device, and storage medium to improve the rationality of standard verification and thereby reduce manual input costs.

[0005] Therefore, in one embodiment of this application, a standard verification method is provided, which is applicable to a management platform and includes:

[0006] When a save request is received from the design terminal for the description information of the application programming interface, a rule check is performed on the description information before saving; the description information is edited by the design user on the design terminal.

[0007] When the rule verification before saving passes, the description information is saved;

[0008] After the description information is saved, when a release request is received from the design terminal for the description information, a pre-release rule verification is performed on the description information to control the release process of the application programming interface.

[0009] The pre-save reference rules used for the pre-save rule verification are mandatory rules; the pre-release reference rules used for the pre-release rule verification are flexible rules.

[0010] In another embodiment of this application, a standard verification method is provided, suitable for designing terminals, comprising:

[0011] A save request is sent to the management platform for the description information of the application programming interface, so that the management platform: performs a pre-save rule verification on the description information, and saves the description information when the pre-save rule verification passes; wherein, the description information is edited by the design user on the design terminal;

[0012] After the description information is saved, a release request is sent to the management platform based on the description information, so that the management platform can: perform pre-release rule verification on the description information to control the release process of the application programming interface;

[0013] The pre-save reference rules used for the pre-save rule verification are mandatory rules; the pre-release reference rules used for the pre-release rule verification are flexible rules.

[0014] In another embodiment of this application, a standard verification method is provided, which is applicable to a management platform and includes:

[0015] When a save request is received from the design terminal for the description information of the published object, a rule verification is performed on the description information before saving; the description information is edited by the design user on the design terminal.

[0016] When the rule verification before saving passes, the description information is saved;

[0017] After the description information is saved, when a publishing request is received from the design terminal for the description information, a pre-publishing rule verification is performed on the description information to control the publishing process of the publishing object.

[0018] Among them, the pre-save reference rules on which the pre-save rule verification is based are mandatory rules; the pre-release reference rules on which the pre-release rule verification is based are flexible rules.

[0019] In another embodiment of this application, a standard verification system is provided, comprising: a management platform and a design terminal;

[0020] The design terminal is used to: send a save request to the management platform for the description information of the application programming interface;

[0021] The management platform is used to: upon receiving the save request, perform pre-save rule verification on the description information; the description information is edited by the design user on the design terminal; and save the description information when the pre-save rule verification passes.

[0022] The design terminal is also used to: after the description information is saved, send a release request to the management platform for the description information;

[0023] The management platform is also used to: when receiving the release request, perform pre-release rule verification on the description information to control the release process of the application programming interface;

[0024] Among them, the pre-save reference rules on which the pre-save rule verification is based are mandatory rules; the pre-release reference rules on which the pre-release rule verification is based are flexible rules.

[0025] In another embodiment of this application, an electronic device is provided. The electronic device includes: a memory and a processor, wherein,

[0026] The memory is used to store programs;

[0027] The processor, coupled to the memory, is used to execute the program stored in the memory to implement the specification verification method described in any of the preceding claims.

[0028] In another embodiment of this application, a computer-readable storage medium storing a computer program is provided, wherein the computer program, when executed by a computer, can implement the specification verification method described in any of the above claims.

[0029] The technical solution provided in this application divides the task of verifying the API description information edited by the design user into two stages: a pre-save stage and a post-save stage. The reference rules used for rule verification in the pre-save stage are mandatory rules, while the reference rules used for rule verification in the pre-release stage are flexible rules. Whether mandatory rules pass or fail affects the normal release of the API, while whether flexible rules pass or fail does not. Furthermore, in practical applications, designers do not immediately release an API after designing it; instead, they make multiple modifications, most of which are flexible. Therefore, performing only mandatory rule verification in the pre-save stage and only flexible rule verification in the pre-release stage not only helps to identify API description information that does not conform to mandatory rules in advance but also avoids the inefficient problem-solving drawbacks of performing flexible rule verification in the pre-save stage. Attached Figure Description

[0030] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0031] Figure 1 This is a schematic diagram of the structure of a specification verification system provided in an embodiment of this application;

[0032] Figure 2 A flowchart illustrating a specification verification method provided in an embodiment of this application;

[0033] Figure 3 A schematic diagram of a funnel verification model provided in an embodiment of this application;

[0034] Figure 4 A flowchart illustrating a specification verification method provided in an embodiment of this application;

[0035] Figure 5 This is a schematic diagram of the structure of a specification verification device provided in an embodiment of this application;

[0036] Figure 6 A flowchart illustrating a specification verification method provided in an embodiment of this application;

[0037] Figure 7 This is a structural block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0038] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of the present application, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of the present application without creative effort are within the scope of protection of the present application.

[0039] Furthermore, some processes described in the specification, claims, and accompanying drawings of this application include multiple operations that appear in a specific order. These operations may be performed out of order or in parallel. Operation numbers such as 101, 102, etc., are merely used to distinguish different operations and do not represent any execution order. Additionally, these processes may include more or fewer operations, and these operations may be performed sequentially or in parallel. It should be noted that the terms "first," "second," etc., used herein are used to distinguish different messages, devices, modules, etc., and do not represent a sequential order, nor do they limit "first" and "second" to different types.

[0040] During the research process, the applicant discovered that: performing rule validation only during design might lead to inefficient problem-solving and a situation where manual input exceeds actual benefits; while validating only during release might result in a high rate of rework and the intervention of reviewers. Therefore, to better balance these two situations, the applicant proposed the specification validation method provided in this application's embodiments. In the technical solution provided in this application's embodiments, the specification validation task for API description information edited by the design user is divided into two stages: a pre-save stage and a post-save stage. The reference rules used for rule validation in the pre-save stage are mandatory rules; the reference rules used for rule validation in the pre-release stage are flexible rules. The pass or failure of mandatory rules affects the normal release of the API, while the pass or failure of flexible rules does not affect the normal release of the API. Furthermore, in practical applications, designers do not immediately release an API after designing it, but rather make multiple modifications, most of which are flexible modifications. Therefore, performing only mandatory rule validation before saving and only flexible rule validation before publishing not only helps to identify API description information that does not conform to mandatory rules in advance before saving, but also avoids the inefficient problem-solving drawbacks of performing flexible rule validation before saving.

[0041] Before introducing the specification verification method provided in the embodiments of this application, the specification verification system involved in the specification verification method provided in the embodiments of this application will be introduced. For example... Figure 1 As shown, the specification verification system may include: a design terminal 101 and a management platform 102. Among them,

[0042] The design terminal 101 is used to: send a save request to the management platform 102 for the description information of the published object;

[0043] The management platform 102 is used to: upon receiving the save request, perform pre-save rule verification on the description information; the description information is edited by the design user on the design terminal 101; and save the description information when the pre-save rule verification passes.

[0044] The design terminal 101 is also used to: after the description information is saved, send a publishing request to the management platform for the description information;

[0045] The management platform is also used to: when receiving the publishing request, perform pre-publishing rule verification on the description information in order to control the publishing process of the publishing object;

[0046] Among them, the pre-save reference rules on which the pre-save rule verification is based are mandatory rules; the pre-release reference rules on which the pre-release rule verification is based are flexible rules.

[0047] In practical applications, the aforementioned publishing objects can be any objects that need to be designed and published, such as APIs, cloud computing elastic resources, API operation policies, applications, etc. In the cloud computing field, the aforementioned APIs may specifically include creation interfaces for creating cloud computing elastic resources, deletion interfaces for deleting cloud computing elastic resources, update interfaces for updating cloud computing elastic resources, etc. The aforementioned cloud computing elastic resources may specifically include: ECS (Elastic Compute Service), containers, disks, etc. The aforementioned API operation policies may include: rate limiting policies, region restriction policies, etc. The aforementioned applications can be any application running on the server side and providing services to clients.

[0048] The description information of the published object is used to define and describe the published object. Taking an API as an example, the API's description information is used to define and describe the API. In practical applications, the above description information can be transmitted and stored in the form of a file, that is, the above description information is specifically a description file.

[0049] Taking an API as an example, the API description information can include: API interface name, API interface function description, request method, input parameters, return value, and Uniform Resource Locator (URL). Publishing an API interface means deploying the API interface code on a target server device, such as a gateway device (which can be called an API gateway device). The API interface code can be automatically generated based on the API interface description file.

[0050] Different publishing targets have different information items included in their respective description information, which can be configured according to actual needs. This application embodiment does not make specific limitations in this regard.

[0051] In practical applications, the design terminal 101 can send save and publish requests to the management platform 102 upon manual triggering by the design user. For example, the design terminal can display a save control and a publish control in the editing interface of the published object. In response to a designer's triggering operation on the save control (e.g., clicking), a save request is sent to the management platform 102; in response to a designer's triggering operation on the publish control (e.g., clicking), a publish request is sent to the management platform 102. To prevent accidental operation by the designer, the publish control can be set to an inactive state in the editing interface before the management platform 102 saves the description file; after the management platform 102 saves the description file, the publish control can be set to an active state in the editing interface. An inactive state means the designer cannot trigger it, while an active state means the designer can trigger it.

[0052] Of course, the design terminal 101 can also send save requests and publish requests to the management platform 102 automatically. For example, if the design terminal detects that the design user has not performed any modification operations within a first preset time period after completing the editing operation in the editing interface, it sends a save request to the management platform 102; if the design terminal detects that the design user has not performed any modification operations within a second preset time period after saving the description file on the management platform 102, it sends a publish request to the management platform 102. The specific durations of the first and second preset time periods can be set according to actual needs, and this embodiment does not impose specific limitations on them.

[0053] In one example, the aforementioned design terminal 101 can be any design terminal such as a mobile phone, tablet computer, or desktop computer. The aforementioned management platform 102 can be composed of one or more servers.

[0054] The specific processing flow of the terminal 101 and the management platform 102 in the above-mentioned specification verification system, as well as the interaction process between the two, will be described in detail in the following embodiments.

[0055] Figure 2 A flowchart illustrating a specification verification method provided in an embodiment of this application is shown. The execution entity of this method can be the management platform 102 in the aforementioned specification verification system. Figure 2 As shown, the method includes:

[0056] 201. When a save request is received from the design terminal for the description information of the published object, a rule verification is performed on the description information before saving.

[0057] The description information is obtained by the design user through editing on the design terminal.

[0058] 202. When the rule verification before saving passes, save the description information.

[0059] 203. After the description information is saved, when a publishing request is received from the design terminal for the description information, a pre-publishing rule verification is performed on the description information to control the publishing process of the publishing object.

[0060] Among them, the pre-save reference rules on which the pre-save rule verification is based are mandatory rules; the pre-release reference rules on which the pre-release rule verification is based are flexible rules.

[0061] In one example of 201 above, the design terminal can display an editing area in the editing interface, where the design user can edit the description information of the published object. In another example, the design terminal can display multiple input boxes in the editing interface, allowing the design user to fill in the corresponding content in each input box.

[0062] In one example, the save request may include a description of the published object. Upon receiving a save request from the design terminal regarding the description of the published object, a pre-save rule check is performed on the description. The pre-save rule check is based on mandatory rules; failure of mandatory rules will inevitably affect the normal publication of the published object; failure of flexible rules may not necessarily affect the normal publication of the published object.

[0063] In practical applications, the pre-save rules used for rule verification can be configured according to actual needs. Typically, all rules involved in this application can be configured by administrators of the management platform. Specifically, the administrator's management terminal can provide a rule configuration interface, allowing administrators to configure the rules to be used and specify whether each rule is mandatory or flexible. The configuration information from the rule configuration interface is then sent to the management platform 102 for storage and can be retrieved directly later.

[0064] In step 202 above, when the rule verification before saving passes, the description information is saved. Simultaneously, the management platform can also send a save success message to the design terminal, which can then provide it to the designer.

[0065] In section 203 above, the pre-release rules used for pre-release rule validation are flexible rules. The pre-save rules used for pre-save rule validation can be configured according to actual needs; please refer to the relevant content above for specific configuration methods.

[0066] In practical applications, if the flexible rule fails, the designer and / or reviewer can be notified that whether or not the release process of the object to be released is affected, or whether or not the release process of the object to be released is executed, is up to the designer or reviewer to decide.

[0067] In one example, the statement in section 203 above, "After the description information is saved, when a release request is received from the design terminal for the description information, a pre-release rule verification is performed on the description information to control the release process of the release object," can be implemented using the following steps:

[0068] After the description information is saved, when a release request is received from the design terminal regarding the description information, at least one pre-release rule on which the pre-release rule verification is based is obtained.

[0069] Determine whether the description information satisfies at least one pre-release rule;

[0070] If the description information does not meet the first pre-release rule in the at least one pre-release rule, a prompt message is sent to the reviewer's review terminal;

[0071] If a pause publishing request is received from the review terminal, triggered by the review user based on the prompt information, then the publishing process of the publishing object is paused.

[0072] If no pause publishing request is received from the review terminal based on the prompt information triggered by the review user, the publishing process of the publishing object continues.

[0073] In another instance, in one example, the statement in section 203 above, "After the description information is saved, when a release request is received from the design terminal for the description information, a pre-release rule verification is performed on the description information to control the release process of the release object," can be implemented using the following steps:

[0074] After the description information is saved, when a release request is received from the design terminal regarding the description information, at least one pre-release rule on which the pre-release rule verification is based is obtained.

[0075] Determine whether the description information satisfies at least one pre-release rule;

[0076] If the description information does not meet the first pre-release rule in the at least one pre-release rule, a prompt message is sent to the design user's design terminal;

[0077] If a pause release request is received from the design terminal, triggered by the design user based on the prompt information, then the release process of the release object is paused.

[0078] If no pause release request is received from the design terminal based on the prompt information triggered by the design user, the release process of the release object continues.

[0079] In another instance, in one example, the statement in section 203 above, "After the description information is saved, when a release request is received from the design terminal for the description information, a pre-release rule verification is performed on the description information to control the release process of the release object," can be implemented using the following steps:

[0080] After the description information is saved, when a release request is received from the design terminal regarding the description information, at least one pre-release rule on which the pre-release rule verification is based is obtained.

[0081] Determine whether the description information satisfies at least one pre-release rule;

[0082] If the description information does not meet the first pre-release rule in the at least one pre-release rule, then a prompt message is sent to the review terminal of the review user and the design terminal of the design user;

[0083] If a pause release request is received from the review terminal based on the prompt information triggered by the review user, or if a pause release request is received from the design terminal based on the prompt information triggered by the design user, then the release process of the release object is paused.

[0084] If no pause release request is received from the review terminal based on the prompt information, and no pause release request is received from the design terminal based on the prompt information, then the release process of the object to be released continues.

[0085] In practical applications, compatibility rules between new and old versions are flexible rules. Generally, during the release process, it's required that the new version's description file be compatible with the old version's description file. This avoids incompatibility issues after the new version is released, which could affect customer usability. For example, a new version API needs to be compatible with an existing API version to prevent customers using the old version from being unable to use it after the new version is released. However, if the designers have already negotiated and agreed on incompatibility issues with customers using the old version before release, then even if the compatibility rule fails, it won't affect the normal release of the new version. The designers only need to report this to the reviewers beforehand. During the pre-release rule validation, any failed compatibility rules can be submitted for manual review. Once the reviewers approve the rule, the release process for the new version can proceed.

[0086] In addition, there are some universal rules regarding word attributes that also fall under the category of flexible rules. Universal rules can be understood as rules that most publishing objects need to follow, but a small portion of publishing objects may not need to. Using such rules during the pre-publishing rule validation process allows for the following: if a rule fails, a warning message can be sent to the designer; if the designer believes the rule needs to be followed, the publishing process can be paused; if the designer believes the rule does not need to be followed, it can be ignored, and the publishing can continue.

[0087] Of course, in practical applications, there may be other rules that are flexible, which will not be listed here.

[0088] The technical solution provided in this application divides the task of verifying the API description information edited by the design user into two stages: a pre-save stage and a post-save stage. The reference rules used for rule verification in the pre-save stage are mandatory rules, while the reference rules used for rule verification in the pre-release stage are flexible rules. Whether mandatory rules pass or fail affects the normal release of the API, while whether flexible rules pass or fail does not. Furthermore, in practical applications, designers do not immediately release an API after designing it; instead, they make multiple modifications, most of which are flexible. Therefore, performing only mandatory rule verification in the pre-save stage and only flexible rule verification in the pre-release stage not only helps to identify API description information that does not conform to mandatory rules in advance but also avoids the inefficient problem-solving drawbacks of performing flexible rule verification in the pre-save stage.

[0089] To improve publishing efficiency and reduce the manual intervention costs for reviewers, a post-save rule validation can be performed on the saved description information. The post-save reference rules used for this validation are the same as the pre-publishing reference rules used for the pre-publishing rule validation. The validation results are then sent to the design terminal. This allows design users to anticipate potential problems during the publishing process and address them in advance, ensuring successful publishing on the first attempt and improving efficiency. Specifically, the above method may further include:

[0090] 204. After the description information is saved, a post-save rule verification is performed on the description information to obtain the post-save verification result.

[0091] 205. The saved verification result is sent to the design terminal so that the design terminal can provide it to the design user.

[0092] The saved post-rule verification is based on the same saved post-reference rule as the published pre-reference rule verification.

[0093] Typically, the above-mentioned post-save rule validation is performed before the above-mentioned publish request is received.

[0094] The user can then determine whether the description information needs to be modified based on the saved verification results. If modification is required, the user can perform the corresponding modification operation on the design terminal. After the modification is completed, the terminal device can send a save request to the management platform again. The specific timing of the terminal device sending the save request and the processing performed by the management platform upon receiving the save request can be found in the corresponding content of the above embodiments, and will not be repeated here.

[0095] In one feasible solution, the step 204 above, "after the description information is saved, a post-save rule verification is performed on the description information to obtain the post-save verification result," can be implemented using the following steps:

[0096] 2041. After the description information is saved, determine whether the description information meets at least one post-save reference rule on which the post-save rule verification is based, and obtain the post-save verification result.

[0097] If the description information does not meet the first post-save reference rule in the at least one post-save reference rule and the first post-save reference rule is of the manual review type, then the first post-save reference rule in the post-save verification result is marked as pending manual review, and / or if the description information does not meet the second post-save reference rule in the at least one post-save reference rule and the second post-save reference rule is of the warning type, then the second post-save reference rule in the verification result is marked as a warning.

[0098] In one example of 2041 above, after the description information is saved, the management platform can obtain at least one saved reference rule on which the saved rule verification is based, and then determine whether the description information meets at least one saved reference rule on which the saved rule verification is based.

[0099] To improve the efficiency of designers' modifications, the above methods may also include:

[0100] 206. For the saved reference rules that are not met by the described information, determine the modification suggestions after saving.

[0101] 207. The saved modification suggestions are sent to the design terminal so that the design terminal can provide them to the design user.

[0102] In one example of 207 above, the suggested modifications after saving and the verification results after saving can be sent together to the design terminal. The design terminal can then display the suggested modifications and the verification results after saving.

[0103] Optionally, the statement in section 203 above, "After the description information is saved, when a release request is received from the design terminal for the description information, a pre-release rule verification is performed on the description information to control the release process of the application programming interface," can be implemented using the following steps:

[0104] 2031. After the description information is saved, when a release request is received from the design terminal for the description information, it is determined whether the description information meets at least one pre-release reference rule on which the pre-release rule verification is based.

[0105] 2032. If the description information does not satisfy the first pre-release reference rule in the at least one pre-release reference rule and the first reference rule is of the manual review type, then send a manual review request for the first pre-release reference rule to the review user.

[0106] 2033. Receive the review result from the review user regarding the manual review request, and determine whether to execute the application programming interface release process.

[0107] In the above 2031, the management platform can obtain at least one pre-release reference rule on which the pre-release rule verification is based, and determine whether the description information satisfies at least one pre-release reference rule on which the pre-release rule verification is based, and obtain the pre-release verification result.

[0108] In the above 2032, if it is determined, based on the pre-release verification result, that the description information does not meet the first pre-release reference rule in the at least one pre-release reference rule and the first reference rule belongs to the manual review type, then a manual review request for the first pre-release reference rule is sent to the review terminal of the review user.

[0109] In the above 2033, if the review result is approved, the publishing process of the publishing object will be executed; if the review result is not approved, the publishing process of the publishing object will not be executed, that is, the publishing process of the publishing object will be suspended.

[0110] When the above-mentioned publishing object is an API interface, and the target gateway device to which the API interface needs to be deployed is of different gateway types, the reference rules for rule verification will be different because the requirements of different gateway devices are different. Therefore, rule verification can be performed on the description information before saving, before publishing, and after saving according to the gateway type.

[0111] In one example, it is possible to configure corresponding reference rule sets for different gateway types, each reference rule set including at least one reference rule; then, establish a correspondence between gateway types and corresponding reference rule sets; subsequently, based on the gateway type and the above correspondence, the corresponding reference rule set can be determined, that is, the at least one reference rule on which the corresponding rule verification is based can be determined.

[0112] Specifically, in section 201 above, "when a save request is received from the design terminal for the description information of the published object, a rule verification is performed on the description information before saving," includes:

[0113] 2011. Based on the gateway type of the target gateway device to which the application programming interface is to be deployed, perform rule verification on the description information before saving, according to the gateway type.

[0114] Specifically, based on the gateway type, a corresponding pre-save reference rule set is determined; the corresponding reference rule set includes at least one pre-save reference rule on which the pre-save rule verification is based; it is determined whether the description information satisfies the at least one pre-save reference rule to obtain the pre-save rule verification result. Different gateway types may correspond to different pre-save reference rule sets.

[0115] Regarding post-save rule validation, the corresponding post-save reference rule set can be determined based on the gateway type. The post-save reference rule set includes at least one post-save reference rule upon which the validation is based. Different gateway types may have different post-save reference rule sets.

[0116] Regarding pre-deployment rule validation, the corresponding pre-deployment reference rule set can be determined based on the gateway type. The pre-deployment reference rule set includes at least one pre-deployment reference rule upon which the pre-deployment rule validation is based. Different gateway types may correspond to different pre-deployment reference rule sets.

[0117] In practical applications, the rule verification steps described above can be performed by the management platform itself or by the management platform requesting the rule engine device to perform them. This embodiment of the application does not specifically limit this. For example, the management platform can send a rule verification request to the rule engine device; this request may carry descriptive information; after receiving the request, the rule engine device obtains at least one reference rule on which the rule verification is based, determines whether the descriptive information satisfies at least one reference rule on which the rule verification is based, and then returns the verification result to the management platform. The aforementioned rule verification request may include: a rule verification request before saving, a rule verification request after saving, and / or a rule verification request before publishing.

[0118] Optionally, the above method may also include:

[0119] 208. If the rule verification before saving fails, the description information shall not be saved.

[0120] 209. Based on the verification results of the pre-save rule verification, send pre-save modification suggestions to the design terminal.

[0121] When saving the description information is prohibited, a modification suggestion before saving can be sent to the design terminal. The design terminal can provide the modification suggestion before saving to the design user, so that the design user can make corresponding modifications according to the modification suggestion before saving. After the modification is completed, the design terminal sends a save request to the management platform again, and the management platform continues to execute the steps in the above embodiments.

[0122] Furthermore, to identify design issues earlier, help users improve design efficiency, and reduce rework costs, the design terminal can perform front-end rule validation during the user's editing of the description information. The pre-save reference rules used for this validation are mandatory rules. For example, after the user completes input in each input box, the design terminal can perform front-end rule validation on the content entered. If the validation passes, the user is allowed to proceed to the next input box; if it fails, the user is prompted to make corrections.

[0123] In practical applications, front-end rule validation mainly involves validating required fields, selection types, and text formats. Typically, front-end rule validation primarily addresses the issue of validation format.

[0124] like Figure 3 As shown, the entire specification verification process provided in this application embodiment is divided into four stages: the first stage is the front-end verification stage 301, the second stage is the pre-save verification stage 302, the third stage is the post-save verification stage 303, and the fourth stage is the pre-release verification stage 304. This achieves the effect of broad-to-specific specification verification in the design and release process of the release object, allowing for processing by level (mandatory level, flexible level, where the flexible level can be further subdivided into warning level and manual review level), and reducing manual input. Figure 3 As shown, the entire standard verification process can be viewed as a funnel verification model, progressing from broad to specialized.

[0125] Figure 4 A flowchart illustrating a specification verification method according to another embodiment of this application is shown. The execution entity of this method can be the design terminal in the aforementioned specification verification system. For example... Figure 4 As shown, the method includes:

[0126] 401. Send a save request to the management platform for the description information of the published object, so that the management platform: performs pre-save rule verification on the description information, and saves the description information when the pre-save rule verification passes;

[0127] The description information is obtained by the design user on the design terminal;

[0128] 402. After the description information is saved, a publishing request is sent to the management platform for the description information, so that the management platform can: perform pre-publishing rule verification for the description information to control the publishing process of the publishing object;

[0129] Among them, the pre-save reference rules on which the pre-save rule verification is based are mandatory rules; the pre-release reference rules on which the pre-release rule verification is based are flexible rules.

[0130] The specific implementation of steps 401 and 402 above can be found in the corresponding contents of the above embodiments, and will not be repeated here.

[0131] The technical solution provided in this application divides the task of verifying the API description information edited by the design user into two stages: a pre-save stage and a post-save stage. The reference rules used for rule verification in the pre-save stage are mandatory rules, while the reference rules used for rule verification in the pre-release stage are flexible rules. Whether mandatory rules pass or fail affects the normal release of the API, while whether flexible rules pass or fail does not. Furthermore, in practical applications, designers do not immediately release an API after designing it; instead, they make multiple modifications, most of which are flexible. Therefore, performing only mandatory rule verification in the pre-save stage and only flexible rule verification in the pre-release stage not only helps to identify API description information that does not conform to mandatory rules in advance but also avoids the inefficient problem-solving drawbacks of performing flexible rule verification in the pre-save stage.

[0132] It should be noted that any steps in the method provided in this application that are not described in detail can be found in the corresponding content of the above embodiments, and will not be repeated here. Furthermore, the method provided in this application may include other parts or all of the steps in the above embodiments in addition to the steps described above; for details, please refer to the corresponding content of the above embodiments, and will not be repeated here.

[0133] The technical solutions provided in this application will be described in detail below, taking into account API design and release scenarios:

[0134] The following guidelines must be followed by users during each stage of the API lifecycle (requirements analysis, design, release, and decommissioning):

[0135] During the requirements analysis phase, review the specifications and integrate them into the API planning. Requirements may include: whether the API can meet a timeout of 10 seconds or less; whether incompatible changes are needed for online implementation, such as: modifying parameter names, adding required parameters, modifying API paths, deleting protocol types, deleting authentication methods, modifying visibility, deleting HTTP methods, etc.

[0136] During the design phase, remember that once the API definition is documented, it will become one of the facets of the cloud product and should not be treated carelessly or casually. The design should adhere to the following naming conventions: API name, parameter name, and error code name; integer and number type parameters in the API should have maximum and minimum values, which should be disclosed to the customer in the documentation; all error codes for the API should be recorded; and RESTful paths should conform to the specified requirements.

[0137] During the release phase, any violations detected by the CI / CD process must be carefully modified and analyzed. If there is no impact on the online release, it must be reported to the reviewers. Release is only permitted after the reviewers have manually reviewed and approved the violation.

[0138] During the offline phase, the offline process will be carried out in accordance with the API specifications.

[0139] In practical applications, every change to the API must be analyzed and tested to determine its impact on the online environment.

[0140] like Figure 5 As shown in the figure, this application provides a specification verification device, which includes: a front-end verification module, a verification storage module, a rule scanning module, and a CI / CD node. Among them,

[0141] The front-end validation module is designed to validate whether the text entered by the user meets the requirements. It is primarily used to validate required fields, selection types, and text formatting.

[0142] The save verification module functions by using different logic to verify API metadata (i.e., the information described above) for different gateway types based on the SPI mechanism. When the user clicks save, the terminal sends a save request to the save verification module. This module performs mandatory verification based on the different gateway types to which the API belongs. If the requirements of the corresponding gateway are not met, saving is prohibited.

[0143] The rule scanning module's function is to scan API metadata according to a set of defined rules, return scan results and suggestions, and notify the user, who can then modify the API design according to the suggested guidelines. This module runs asynchronously and has no impact on the user's API design experience.

[0144] The CI / CD node's function is to integrate rule scanning capabilities into the CI / CD process. When a user deploys the process API and passes through this node, the rule scanning module will be automatically invoked to perform rule scanning and review.

[0145] In addition, to ensure the proper functioning of the standard verification device, a rule operation platform and rule engine equipment are also required; among them,

[0146] The rule operation platform allows for the visual configuration and publication of rules using a DSL (Domain Specific Language) approach, enables versioned rule management, and categorizes rules based on different scenarios (different publishing objects correspond to different scenarios). Therefore, it is also suitable for specification checks in various scenarios.

[0147] The rule engine device is designed to implement a feature-rich and highly scalable compiler executor that executes remote call instructions from the management platform during the process of "word decomposition -> word type analysis -> syntax analysis -> production runtime instruction set -> execution of generated instruction set" in order to invoke atomic rules (i.e., the aforementioned reference rules).

[0148] Figure 6 A flowchart illustrating the specification validation methods for the API is shown. (For example...) Figure 6 As shown,

[0149] Step 110: Verify the input information through the front end, then proceed to step 120;

[0150] Step 120: Determine whether the current task is to save or publish the API. If it is to save, proceed to step 130; if it is to publish, proceed to step 200.

[0151] Step 130: The backend pulls the API metadata S, parses it into model M, and jumps to step 140;

[0152] Here, model M is also the interface code of the API. Parsing S into M facilitates subsequent rule validation.

[0153] Step 140: Determine the SPI verification service based on the API type, perform verification through the SPI verification service, and proceed to step 150;

[0154] Step 150: Determine if the SPI verification is successful. If yes, proceed to step 160; otherwise, proceed to the end. If the verification fails, saving the API is not allowed.

[0155] Step 160: Asynchronously call the rule verification module to perform rule checks (i.e., rule validation), then jump to step 170;

[0156] Step 170: Call the rule engine to execute the rule set Ri corresponding to the API scenario, and jump to step 180;

[0157] Step 180: Collect the execution results of the rule engine, then proceed to step 190;

[0158] Step 190: If saving, notify the designer of the result and proceed to the end; if publishing, proceed to step 210.

[0159] Step 200: Deploy the API via the CI / CD process, then proceed to step 160;

[0160] Step 210: Determine whether the rule engine execution result is satisfactory. If yes, continue to the next node in the CI / CD process and jump to the end; otherwise, jump to step 220.

[0161] Step 220: If the rule fails, initiate manual review. After manual review, continue to the next node in the CI / CD process and jump to the end.

[0162] In summary, this application provides an API specification check implementation solution and corresponding device, which can quickly realize specification checks for entities designed based on YAML and JSON and released through a process. Compared with specification verification relying on a single location, this invention adopts a phased specification verification, dividing rules into stages and strict levels, and performing checks at different levels and in different ways at the front end, save, after save, and before release. This helps designers efficiently locate and handle problems, while reducing unnecessary manual review and rework, increasing the automated review pass rate by more than 50% compared to single-location review. Furthermore, through a unified operating logic, it enables extended verification of different scenarios and entities in a unified mode; it also realizes dynamic configuration of rules to cope with special scenarios requiring sudden increases or decreases; and it can be embedded in the CI / CD process to achieve automated review. The technical solution provided by this application can realize the rule operation, verification, dynamic management, and automatic review of APIs through graphical interface operation, and the specification records of each version can be traced afterward, realizing a standardized, process-oriented, automated, and scalable specification check process.

[0163] Figure 7 A schematic diagram of the structure of an electronic device according to an embodiment of this application is shown. Figure 7As shown, the electronic device includes a memory 1101 and a processor 1102. The memory 1101 can be configured to store various other data to support operation on the electronic device. Examples of such data include instructions for any application or method used to operate on the electronic device. The memory 1101 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0164] The memory 1101 is used to store programs;

[0165] The processor 1102 is coupled to the memory 1101 and is used to execute the program stored in the memory 1101 to implement the standard verification method provided in the above method embodiments.

[0166] Furthermore, such as Figure 7 As shown, the electronic device also includes: communication component 1103, display 1104, power supply component 1105, audio component 1106, and other components. Figure 7 The diagram only shows some components and does not mean that the electronic device includes only these components. Figure 7 The components shown.

[0167] Accordingly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a computer, can implement the steps or functions of the specification verification methods provided in the above-described method embodiments.

[0168] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0169] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0170] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A standard verification method, wherein, Suitable for management platforms, including: When a save request is received from the design terminal in response to a save operation by the design user for the description information of the application programming interface, a pre-save rule verification is performed on the description information; the description information is edited by the design user on the design terminal; the description information is the metadata of the application programming interface; the design terminal performs front-end rule verification during the process of the design user editing the description information; When the rule verification before saving passes, the description information is saved; After the description information is saved, a post-save rule verification is performed on the description information to obtain the post-save verification result. The saved verification result is sent to the design terminal so that it can be provided to the design user. After the description information is saved, when the design terminal receives a release request sent by the design user in response to the release operation of the description information, a pre-release rule verification is performed on the description information to control the release process of the application programming interface. The pre-save reference rule used for the pre-save rule verification is a mandatory rule; the pre-release reference rule used for the pre-release rule verification is a flexible rule; and the post-save reference rule used for the post-save rule verification is the same as the pre-release reference rule used for the pre-release rule verification.

2. The method according to claim 1, wherein, After the description information is saved, a post-save rule validation is performed on the description information to obtain the post-save validation result, including: After the description information is saved, it is determined whether the description information meets at least one post-save reference rule on which the post-save rule verification is based, and the post-save verification result is obtained. When the description information does not meet the first post-save reference rule in the at least one post-save reference rule and the first post-save reference rule belongs to the manual review type, the first post-save reference rule in the post-save verification result is marked as pending manual review; and / or, when the description information does not meet the second post-save reference rule in the at least one post-save reference rule and the second post-save reference rule belongs to the warning type, the second post-save reference rule in the verification result is marked as a warning.

3. The method according to claim 2, wherein, Also includes: For the saved reference rules that are not met by the described information, determine the modification suggestions after saving; The saved modification suggestions are sent to the design terminal so that the design terminal can provide them to the design user.

4. The method according to any one of claims 1 to 3, wherein, After the description information is saved, when a release request is received from the design terminal in response to the design user's release operation on the description information, a pre-release rule check is performed on the description information to control the release process of the application programming interface, including: After the description information is saved, when a release request is received from the design terminal for the description information, it is determined whether the description information meets at least one pre-release reference rule on which the pre-release rule verification is based. If the description information does not meet the first pre-release reference rule in the at least one pre-release reference rule and the first pre-release reference rule is of the manual review type, then a manual review request for the first pre-release reference rule is sent to the review user. Based on the review results of the review user regarding the manual review request, determine whether to execute the application programming interface (API) release process.

5. The method according to any one of claims 1 to 3, wherein, When the design terminal receives a save request in response to a user's save operation on the description information of the application programming interface, it performs pre-save rule validation on the description information, including: Based on the gateway type of the target gateway device to which the application programming interface needs to be deployed, rule verification is performed on the description information before saving, according to the gateway type.

6. The method according to any one of claims 1 to 3, wherein, Also includes: If the rule verification before saving fails, the description information shall not be saved; Based on the verification results of the pre-save rule check, a pre-save modification suggestion is sent to the design terminal.

7. A standardized verification method, applicable to terminal design, wherein, include: Front-end rule validation is performed during the design of the description information for the user-editable application programming interface; In response to the user's save operation on the description information of the application programming interface, a save request is sent to the management platform, so that the management platform: performs pre-save rule verification on the description information, and saves the description information when the pre-save rule verification passes; wherein, the description information is edited by the user on the design terminal; the description information is the metadata of the application programming interface; after the description information is saved, the management platform performs post-save rule verification on the description information to obtain the post-save verification result; Receive the saved verification result sent by the management platform and provide it to the design user; After the description information is saved, in response to the user's publishing operation on the description information, a publishing request is sent to the management platform so that the management platform can: perform pre-publishing rule verification on the description information to control the publishing process of the application programming interface; The pre-save reference rule used for the pre-save rule verification is a mandatory rule; the pre-release reference rule used for the pre-release rule verification is a flexible rule; and the post-save reference rule used for the post-save rule verification is the same as the pre-release reference rule used for the pre-release rule verification.

8. A standard verification system, wherein, include: Management platform and design terminal; The design terminal is used to: perform front-end rule validation during the process of designing the description information of the user-edited application programming interface; In response to a user's save operation on the description information of the application programming interface, a save request is sent to the management platform; the description information is the metadata of the application programming interface. The management platform is used to: upon receiving the save request, perform pre-save rule verification on the description information; the description information is edited by the design user on the design terminal; when the pre-save rule verification passes, save the description information; after the description information is saved, perform post-save rule verification on the description information to obtain the post-save verification result; The design terminal is also used to: receive the saved verification result sent by the management platform and provide it to the design user; after the description information is saved, in response to the design user's publishing operation on the description information, send a publishing request to the management platform; The management platform is also used to: when receiving the release request, perform pre-release rule verification on the description information to control the release process of the application programming interface; The pre-save reference rule used for the pre-save rule verification is a mandatory rule; the pre-release reference rule used for the pre-release rule verification is a flexible rule; and the post-save reference rule used for the post-save rule verification is the same as the pre-release reference rule used for the pre-release rule verification.

9. An electronic device, wherein, include: Memory and processor, among which, The memory is used to store programs; The processor, coupled to the memory, is used to execute the program stored in the memory to implement the specification verification method according to any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, wherein, When the computer program is executed by a computer, it can implement the standard verification method according to any one of claims 1 to 7.

Images