RESTful atomic power interface aggregation method and device

Abstract

The invention provides a RESTful atomic power interface aggregation method and device, and the method comprises the steps: creating a RESTful atomic power information table which is used for filling and storing the basic information of the original atomic power; programming language rules are formulated to create a capability template, then the capabilities of a plurality of native atoms are aggregated according to specified logic by using the structure and grammar of the programming language to obtain an aggregation capability, and basic information of the aggregation capability is filled into a RESTful atomic capability information table; calling an aggregation capability; and storing the aggregation capability calling record and the native atomic capability calling record into a capability calling log table. In this way, default processing rules of the RESTful atomic power interface are all built-in, common functions are functionalized and modularized, flexible parameter variables, formats and the like are all externally played, a set of general processing model of the RESTful power interface is formed, the development speed of new power is increased, the calling frequency of native power is reduced, and the overall performance is improved.

Description

Technical Field

[0001] Embodiments of the present invention generally relate to the technical field of software system interface opening, and in particular, to a method and device for aggregating RESTful atomic capability interfaces. Background Art

[0002] The functions and roles of atomic capability interfaces provided by different systems are themselves scattered and disorderly. However, through encapsulation and aggregation according to certain rules, some more meaningful new capability interfaces can be formed. For example, some functional-level query capabilities can be upgraded to business-level queries through encapsulation and aggregation, which are more oriented to the actual usage scenarios of users.

[0003] In various current network management platforms, the requirements for the invocation, encapsulation, and aggregation of such atomic capability interfaces are increasing, and the process orchestration scenarios are diverse and the complexity is increasing. Therefore, a technology is needed to solve the rapid development and debugging of capability interfaces, as well as the implementation of some complex orchestration processes. Summary of the Invention

[0004] To solve the above problems, the present invention builds in all the default processing rules of RESTful atomic capability interfaces, functionalizes and modularizes common functions, and fully exposes flexible parameter variables and formats, etc., to form a general processing model for RESTful capability interfaces, which has high applicability, speeds up the development speed of new capabilities, reduces the number of invocations of native capabilities, improves the overall performance, and realizes unified management.

[0005] According to an embodiment of the present invention, a method and device for aggregating RESTful atomic capability interfaces are provided.

[0006] In a first aspect of the present invention, a method for aggregating RESTful atomic capability interfaces is provided. The method includes:

[0007] S01: Create a RESTful atomic capability information table for filling and storing the basic information of native atomic capabilities, including: capability code, capability name, request method, capability type, capability URL, request message header, request message, response message header, response message, capability template, authentication code;

[0008] S02: Formulate programming language rules to create a capability template, and then aggregate multiple native atomic capabilities according to the specified logic using the structure and syntax of the programming language itself to obtain an aggregated capability, and fill the basic information of the aggregated capability into the RESTful atomic capability information table;

[0009] S03: Invoke the aggregation capability: Check if there is a value for the capability authentication code. If there is no value, this capability does not require authentication; if there is a value, this capability requires authentication. Add the fields and values that need to be authenticated for the authentication code to the authentication information table. Check if the atomic capability meets the authentication information. If it does not meet the requirements, reject the access and return the error code 401 and a prompt indicating authentication failure. If it meets the requirements, perform parameter verification as needed. If the parameter verification fails, return the error code 402 and a failure information prompt. If the parameter verification is successful, assemble the input parameter message required by the native atomic capability and call one or more native atomic capabilities in parallel or serially to obtain the return result.

[0010] S04: Store the aggregation capability call record and the native atomic capability call record in the capability call log table.

[0011] Furthermore, the aggregation capability described in S02 is provided as a new capability interface for external system calls or new aggregation operations within the system.

[0012] Furthermore, the parameter verification described in S03 is used to check if any input parameter has a value and meets the corresponding format.

[0013] Furthermore, if the parameter verification is successful in S03, assemble the input parameter message required by the native atomic capability and call one or more native atomic capabilities in parallel or serially to obtain the return result. If the native atomic capability call fails, return the error code 201 and an exception information prompt. If the native atomic capability call is successful, judge its return result. If the result does not meet the expected result, return other status codes and corresponding prompts according to the interface agreement. If the result meets the expected result, set the return status code to 200, assemble the necessary data into the output parameter data structure, and check if there is a URL callback address in the input parameter message header. If there is a URL callback address in the input parameter message header, asynchronously return the status code and the corresponding output parameter message by calling the callback address. If there is no URL callback address, return the result and the output parameter message in a synchronous manner.

[0014] Furthermore, the data in the capability call log table described in S04 includes: capability code, request header, request message, response status code, exception description, response header, response message, call time, and end time.

[0015] In the second aspect of the present invention, a device for aggregating RESTful atomic capability interfaces is provided. The device includes:

[0016] Creation Module: It is used to create a RESTful atomic capability information table for filling in and storing the basic information of native atomic capabilities, including: capability code, capability name, request method, capability type, capability URL, request message header, request message, response message header, response message, capability template, and authentication code;

[0017] Aggregation Module: It is used to create a capability template by formulating programming language rules, and then aggregate multiple native atomic capabilities according to the specified logic using the structure and syntax of the programming language itself to obtain an aggregated capability, and fill in the basic information of the aggregated capability into the RESTful atomic capability information table;

[0018] Invocation Module: It is used to invoke the aggregated capability: determine whether the capability authentication code has a value. If it has no value, this capability does not require authentication; if it has a value, this capability requires authentication, and add the fields and values that require authentication of the authentication code to the authentication information table; determine whether the atomic capability meets the authentication information. If it does not meet the requirements, access will be denied, and an error code 401 and a prompt for authentication failure will be returned; if it meets the requirements, parameter verification will be performed as needed. If the parameter verification fails, an error code 402 and a failure message prompt will be returned; if the parameter verification is successful, the input parameter message required by the native atomic capability will be assembled, and one or more native atomic capabilities will be invoked in parallel or serially to obtain the return result;

[0019] Storage Module: It is used to store the aggregated capability invocation records and native atomic capability invocation records into the capability invocation log table.

[0020] Furthermore, the aggregated capability described in the aggregation module is used as a new capability interface for external system calls or for new aggregation operations within the system.

[0021] Furthermore, the parameter verification described in the invocation module is used to determine whether any input parameter has a value and whether it meets the corresponding format.

[0022] Furthermore, if the parameter verification is successful in the invocation module, the input parameter message required by the native atomic capability will be assembled, and one or more native atomic capabilities will be invoked in parallel or serially to obtain the return result. If the native atomic capability invocation fails, an error code 201 and an error message prompt will be returned; if the native atomic capability invocation is successful, its return result will be judged. If the result does not meet the expected result, other status codes and corresponding prompts will be returned according to the interface agreement; if the result meets the expected result, the return status code will be set to 200, and the necessary data will be assembled into the output parameter data structure, and it will be judged whether there is a URL callback address in the input parameter message header. If there is a URL callback address in the input parameter message header, the status code and the corresponding output parameter data message will be asynchronously returned by calling the callback address. If there is no URL callback address, the return result and the output parameter message will be returned synchronously.

[0023] Further, the data in the ability call log table in the storage module includes: ability code, request header, request message, response status code, exception description, response header, response message, call time, and end time.

[0024] The above-mentioned English abbreviation interpretations are as follows:

[0025] RESTful: A common REST (Representational State Transfer) application, which is currently the most popular interface design specification. Generally, HTTP POST (or GET) is used for data interaction, and both the request data and the response data are in JSON format (or XML).

[0026] URL: Uniform Resource Locator (or Uniform Resource Locator / Location Address, URL Address), and sometimes it is also commonly referred to as a web address (website address).

[0027] In the present invention, by building in the default processing rules of the RESTful atomic ability interface, functionalizing and modularizing common functions, and fully externalizing flexible parameter variables and formats, a general processing model for the RESTful ability interface is formed, which has high applicability, speeds up the development speed of new abilities, reduces the number of calls to native abilities, improves the overall performance, and realizes unified management.

[0028] It should be understood that the content described in the Summary of the Invention section is not intended to limit the key or important features of the embodiments of the present invention, nor is it used to limit the scope of the present invention. Other features of the present invention will become easily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] In combination with the accompanying drawings and with reference to the following detailed description, the above and other features, advantages, and aspects of the embodiments of the present invention will become more apparent. Among them:

[0030] Figure 1 Shows a flowchart of the aggregation method of the RESTful atomic ability interface according to an embodiment of the present invention;

[0031] Figure 2 Shows a block diagram of the device for aggregating the RESTful atomic ability interface according to an embodiment of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0032] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention. Apparently, the described embodiments are some, but not all, of the embodiments of the present invention. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

[0033] According to an embodiment of the present invention, a method and device for aggregating RESTful atomic capability interfaces are provided. By building in all the default processing rules of RESTful atomic capability interfaces, functionalizing and modularizing common functions, and fully externalizing flexible parameter variables and formats, a general processing model for RESTful capability interfaces is formed. It has high applicability, speeds up the development of new capabilities, reduces the number of calls to native capabilities, improves overall performance, and realizes unified management.

[0034] Next, with reference to several representative embodiments of the present invention, the principles and spirit of the present invention will be elaborated in detail.

[0035] Figure 1 It is a schematic flowchart of a method for aggregating RESTful atomic capability interfaces according to an embodiment of the present invention. The method includes:

[0036] S01: Create a RESTful atomic capability information table for filling and storing the basic information of native atomic capabilities, including: capability code, capability name, request method, capability type, capability URL, request message header, request message, response message header, response message, capability template, and authentication code;

[0037] S02: Develop programming language rules to create a capability template, and then aggregate multiple native atomic capabilities according to the specified logic using the structure and syntax of the programming language itself to obtain an aggregated capability, and fill the basic information of the aggregated capability into the RESTful atomic capability information table;

[0038] S03: Invoke the aggregated capability: Determine whether the capability authentication code has a value. If it has no value, this capability does not require authentication; if it has a value, this capability requires authentication, and add the fields and values that require authentication for the authentication code to the authentication information table; Determine whether the atomic capability meets the authentication information. If it does not meet, access is refused, and an error code 401 and a prompt for authentication failure are returned; if it meets, parameter verification is performed as needed. If the parameter verification fails, an error code 402 and a failure information prompt are returned; if the parameter verification is successful, the input parameter message required by the native atomic capability is assembled, and one or more native atomic capabilities are called in parallel or serially to obtain the return result;

[0039] S04: Store the aggregated ability call records and native atomic ability call records into the ability call log table.

[0040] It should be noted that although the operations of the method of the present invention are described in a specific order in the above embodiments and accompanying drawings, this does not require or imply that these operations must be performed in that specific order, or that all the operations shown must be performed to achieve the desired result. Additionally or alternatively, some steps may be omitted, multiple steps may be combined into one step for execution, and / or one step may be decomposed into multiple steps for execution.

[0041] To more clearly explain the method for aggregating the above RESTful atomic ability interfaces, the following will be described in conjunction with a specific embodiment. However, it should be noted that this embodiment is only for better explaining the present invention and does not constitute an improper limitation to the present invention.

[0042] The following will further illustrate the method for aggregating RESTful atomic ability interfaces in more detail with a specific example:

[0043] Create three tables, namely the atomic ability information table, the authentication information table, and the ability call log table.

[0044] The creation process of the atomic ability information table is as follows:

[0045] CREATE TABLE `cap_info`(

[0046] `cap_code` varchar(32) NOT NULL COMMENT 'Ability code',

[0047] `cap_name` varchar(100) NOT NULL COMMENT 'Ability name',

[0048] `cap_method` varchar(32) NOT NULL DEFAULT 'POST' COMMENT 'Request method',

[0049] `cap_type` varchar(10) NOT NULL DEFAULT 'inner' COMMENT 'Ability type, inner: internal ability; outer: external ability',

[0050] `cap_url` varchar(100) DEFAULT NULL COMMENT 'Ability URL',

[0051] `req_header` varchar(255) DEFAULT NULL COMMENT 'Request message header',

[0052] `req_body` varchar(2000) DEFAULT NULL COMMENT 'Request message',

[0053] `rsp_header` varchar(255) DEFAULT NULL COMMENT 'Response message header',

[0054] `rsp_body` varchar(2000) DEFAULT NULL COMMENT 'Response message',

[0055] `cap_template` longtext COMMENT 'Capability template',

[0056] `auth_code` varchar(64) DEFAULT NULL COMMENT 'Authentication code',

[0057] PRIMARY KEY(`cap_code`) USING BTREE,

[0058] KEY `idx_cap_direct`(`cap_type`) USING BTREE

[0059] ) ENGINE=InnoDB DEFAULT CHARSET=utf8 ROW_FORMAT=DYNAMIC COMMENT='Capability information table';

[0060] The creation process of the authentication information table is as follows:

[0061] CREATE TABLE `auth_info`(

[0062] `auth_code` varchar(64) NOT NULL COMMENT 'Authentication code',

[0063] `auth_key` varchar(100) NOT NULL COMMENT 'Authentication field',

[0064] `auth_value` varchar(100) NOT NULL COMMENT 'Authentication value',

[0065] PRIMARY KEY(`auth_tmpl`, `auth_key`) USING BTREE

[0066] ) ENGINE=InnoDB DEFAULT CHARSET=utf8 ROW_FORMAT=DYNAMIC COMMENT='Authentication information table';

[0067] The creation process of the ability call log table is as follows:

[0068] CREATE TABLE `cap_call_log` (

[0069] `cap_code` varchar(32) NOT NULL COMMENT 'Ability code',

[0070] `req_header` varchar(1000) DEFAULT NULL COMMENT 'Request message header',

[0071] `req_body` longtext COMMENT 'Request message',

[0072] `ret_code` varchar(10) DEFAULT NULL COMMENT 'Response status code',

[0073] `error_msg` varchar(255) DEFAULT NULL COMMENT 'Exception description',

[0074] `rsp_header` varchar(1000) DEFAULT NULL COMMENT 'Response message header',

[0075] `rsp_body` longtext COMMENT 'Response message',

[0076] `call_time` datetime DEFAULT CURRENT_TIMESTAMP COMMENT 'Call time',

[0077] `end_time` datetime DEFAULT NULL COMMENT 'End time',

[0078] KEY `idx_cap_call_cap` (`cap_code`) USING BTREE,

[0079] KEY `idx_cap_call_time`(`call_time`) USING BTREE

[0080] ) ENGINE = InnoDB DEFAULT CHARSET = utf8 ROW_FORMAT = DYNAMIC COMMENT = 'Capability call log table';

[0081] Fill in the information of two atomic native capabilities in the atomic capability information table:

[0082] 1. Native atomic capability to query device information:

[0083] INSERT INTO cap_info(cap_code, cap_name, cap_method, cap_type, cap_url, req_header, req_body, rsp_header, rsp_body, auth_code, cap_template)

[0084] VALUES('dev_info', 'Query device information', 'POST', 'outer', 'http: / / 192.168.1.100:101 / device / getdevinfo', NULL, '{"mgmtip":"1.1.1.1"}', NULL, '{"devname":"shebei1","specialty":"MAN"}', NULL, NULL);

[0085] 2. Native atomic capability to shut down ISIS for the MAN specialty:

[0086] INSERT INTO cap_info(cap_code, cap_name, cap_method, cap_type, cap_url, req_header, req_body, rsp_header, rsp_body, auth_code, cap_template)

[0087] VALUES('MAN_isis_shut','ISIS shutdown for Metropolitan Area Network','POST','outer','http: / / 192.168.1.100:102 / deviceoperate / ISIS_shutdown', NULL,'{"DeviceIP":"1.1.1.1","portname":"Gi1 / 1"}', NULL,'{"resultId":"0000","resultDesc":"succ","resultData":{"rawResult":"xxxxx"}}',NULL,NULL);

[0088] Develop the ability to create programming language rules to create a capability template. Use the if statement to connect the native atomic capability of querying device information and the native atomic capability of ISIS shutdown for the Metropolitan Area Network specialty. If the abnormal situation is met, exit abnormally in advance. Otherwise, splice the native atomic capability code of ISIS shutdown for the Metropolitan Area Network specialty according to the result of the native atomic capability of querying device information and call it to obtain the aggregated capability. Then fill in the basic information of the aggregated capability into the RESTful atomic capability information table:

[0089] INSERT INTO cap_info(cap_code,cap_name,cap_method,cap_type,cap_url,req_header,req_body,rsp_header,rsp_body,auth_code,cap_template)

[0090] VALUES('isis_shutdown','ISIS Shutdown','POST','inner','http: / / 127.0.0.1:1234 / config / isis_shutdown', NULL,'{"deviceip":"1.1.1.1","portid":"Gi1 / 1"}',NULL,'{"retcode":"200","resultId":"0000","resultDesc":"succ","resultData":""}',NULL,'authtest','&checkpara(”deviceip,portid”);

[0091] &callcap(”dev_info”,”{"mgmtip":"”.$input->{deviceip}.”"}”,”devinfo”,10);

[0092] if (${devinfo}{specialty} eq "") {

[0093] &end("202", "External interface call exception, device specialty not found");

[0094] }

[0095] &callcap(${devinfo}{specialty}."_isis_shut",

[0096] "{"DeviceIP":"".$input->{deviceip}."","portname":"".$input->{portid}.""}", "isis", 20);

[0097] if (${isis} eq "") {

[0098] &end("201", "External interface call exception, isis shutdown operation failed");

[0099] }

[0100] $output->{resultId} = ${isis}{resultId};

[0101] $output->{resultDesc} = ${isis}{resultDesc};

[0102] $output->{resultData} = ${isis}{resultData}{rawResult};

[0103] if ($output->{resultId} ne "0000") {

[0104] &end("205", "External interface call result exception");

[0105] }

[0106] )

[0107] Call aggregation ability: curl http: / / 127.0.0.1:1234 / config / isis_shutdown -H "APP-ID:1234567890" -H "APP-KEY:abcdefghijk" -d '{"deviceip":"1.1.1.1","portid":"Gi1 / 1"}'.

[0108] Next, judge the ability authentication code. If this ability requires authentication, add the fields and values that need to be authenticated in the authentication information table: INSERT INTO auth_info(auth_code,auth_key,auth_value) VALUES('authtest','APP-ID','1234567890');

[0109] INSERT INTO auth_info(auth_code,auth_key,auth_value) VALUES('authtest','APP-KEY','abcdefghijk');

[0110] Judge whether the aggregated ability meets the authentication information, that is, judge whether the field APP-ID is 1234**** and APP-KEY is abcdefghijk. If both are met, perform parameter verification as required: Judge that the values of the input parameters deviceip and portid fields are not empty, then the parameter verification is successful. Assemble the input parameter message required for the native atomic ability: Assemble the new input parameter message {"mgmtip":"1.1.1.1"} and call the ability to query device information (the ability code is dev_info). Call the ability call log table for recording. If the value of the specialty field in the returned result of the ability to query device information is not empty, then assemble the new input parameter message {"DeviceIP":"1.1.1.1","portname":"Gi1 / 1"}. Call the ISIS shutdown ability corresponding to the corresponding specialty according to the value of the device specialty field. For example, if the specialty value is MAN, call the ability with the ability code MAN_isis_shut. Call the ability call log table for recording. If the ability call result is not empty, assign the MAN_isis_shut ability call result to the output parameter of the aggregated ability. If the value of the result identification field resultId is 0000, return the normal status code 200 and the corresponding output parameter data. The aggregated ability return message is:

[0111] {"retcode":"200","resultId":"0000","resultDesc":"succ","resultData":""}, which means that the aggregated ability call is successful. Judge that there is no URL callback address, then return the result and the output parameter message in a synchronous manner.

[0112] Determine whether the input parameter message header carries a URL callback address. If the input parameter message header carries a URL callback address, asynchronously return the status code and the corresponding output parameter data message by calling the callback address. If there is no URL callback address, return the result and the output parameter message in a synchronous manner.

[0113] Finally, store the aggregation capability call record in the capability call log table.

[0114] In this embodiment, if the authentication information is not satisfied when the aggregation capability is called, return the error code 401 and a prompt for authentication failure;

[0115] If any of the values of the input parameter fields deviceip and portid is empty, the input parameter verification fails, and return the error code 402 and a failure information prompt;

[0116] Assemble the new input parameter message {"mgmtip":"1.1.1.1"} and call the capability to query device information (the capability code is dev_info). Record the call in the capability call log table. If the value of the specialty field in the result of querying device information is empty, return the error code 202 and a failure information prompt;

[0117] Assemble the new input parameter message {"DeviceIP":"1.1.1.1","portname":"Gi1 / 1"}, and call the ISIS shutdown capability corresponding to the corresponding specialty according to the value of the device specialty field. For example, if the specialty value is MAN, call the capability with the capability code MAN_isis_shut. Record the call in the capability call log table. If the capability call result is empty, return the error code 201 and a failure information prompt;

[0118] Assign the result of the MAN_isis_shut capability call to the output parameter of the aggregation capability. If the value of the result identification field resultId is not 0000, return the error code 205 and a failure information prompt;

[0119] If there is a callback field in the input parameter message header, it carries a URL callback address, and asynchronously return the status code and the corresponding output parameter data message by calling the callback address.

[0120] Based on the same inventive concept, the present invention also proposes an apparatus for aggregating RESTful atomic capability interfaces. The implementation of this apparatus can refer to the implementation of the above method, and the repeated parts will not be described again. As Figure 2 shown, the apparatus 100 includes:

[0121] Creation Module 101: Used to create a RESTful atomic capability information table for filling in and storing the basic information of native atomic capabilities, including: capability encoding, capability name, request method, capability type, capability URL, request message header, request message, response message header, response message, capability template, authentication encoding;

[0122] Aggregation Module 102: Used to formulate programming language rules to create a capability template, and then aggregate multiple native atomic capabilities according to the specified logic using the structure and syntax of the programming language itself to obtain an aggregated capability, and fill in the basic information of the aggregated capability into the RESTful atomic capability information table;

[0123] Invocation Module 103: Used to invoke the aggregated capability: Determine whether the capability authentication encoding has a value. If it has no value, this capability does not require authentication; if it has a value, this capability requires authentication, and add the fields and values that require authentication for the authentication encoding in the authentication information table; Determine whether the atomic capability meets the authentication information. If it does not meet, access is refused, and an error code 401 and a prompt for authentication failure are returned; if it meets, parameter verification is performed as required. If the parameter verification fails, an error code 402 and a failure information prompt are returned; if the parameter verification is successful, the input parameter message required by the native atomic capability is assembled, and one or more native atomic capabilities are invoked in parallel or serially to obtain the return result;

[0124] Storage Module 104: Used to store the aggregated capability invocation record and the native atomic capability invocation record into the capability invocation log table.

[0125] An apparatus for aggregating RESTful atomic capability interfaces proposed by the present invention has built-in all the default processing rules of the RESTful atomic capability interfaces, functionalizes and modularizes common functions, and fully externalizes flexible parameter variables and formats, forming a general processing model for RESTful capability interfaces, with high applicability, accelerating the development speed of new capabilities, reducing the number of invocations of native capabilities, improving the overall performance, and achieving unified management.

[0126] Although the spirit and principles of the present invention have been described with reference to several specific embodiments, it should be understood that the present invention is not limited to the disclosed specific embodiments, and the division of each aspect does not mean that the features in these aspects cannot be combined for benefit. This division is only for the convenience of expression. The present invention aims to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims.

[0127] Regarding the limitations on the protection scope of the present invention, those skilled in the art should understand that based on the technical solutions of the present invention, various modifications or deformations that can be made by those skilled in the art without creative labor are still within the protection scope of the present invention.

Claims

1. A method for aggregating RESTful atomic capability interfaces, characterized in that The method includes: S01: Create a RESTful atomic capability information table for filling in and storing the basic information of native atomic capabilities, including: capability code, capability name, request method, capability type, capability URL, request message header, request message, response message header, response message, capability template, authentication code; S02: Develop programming language rules to create a capability template, and then aggregate multiple native atomic capabilities according to the specified logic using the structure and syntax of the programming language itself to obtain an aggregated capability, and fill in the basic information of the aggregated capability into the RESTful atomic capability information table; S03: Invoke the aggregated capability: Determine whether the capability authentication code has a value. If it has no value, this capability does not require authentication; if it has a value, this capability requires authentication, and add the fields and values that need to be authenticated by the authentication code to the authentication information table; Determine whether the atomic capability meets the authentication information. If it does not meet the requirements, access is refused, and an error code 401 and a prompt for authentication failure are returned; if it meets the requirements, parameter verification is performed as needed. If the parameter verification fails, an error code 402 and a failure information prompt are returned; if the parameter verification is successful, assemble the input parameter message required by the native atomic capability, and call one or more native atomic capabilities in parallel or serially to obtain the return result; S04: Store the aggregated capability call record and the native atomic capability call record in the capability call log table.

2. The method for aggregating a RESTful atomic capability interface according to claim 1, wherein The aggregated capability described in S02 is used as a new capability interface for external system calls or for new aggregation operations within the system.

3. A method for aggregating RESTful atomic capability interfaces according to claim 1, characterized in that The parameter verification described in S03 is used to determine whether any input parameter has a value and whether it meets the corresponding format.

4. A method for aggregating RESTful atomic capability interfaces according to claim 1, characterized in that, If the parameter verification is successful as described in S03, assemble the input parameter message required by the native atomic capability, call one or more native atomic capabilities in parallel or serially to obtain the return result. If the native atomic capability call fails, an error code 201 and an error information prompt are returned; If the native atomic capability call is successful, judge its return result. If the result does not meet the expected result, return other status codes and corresponding prompts according to the interface agreement; if it meets the expected result, set the return status code to 200, assemble the necessary data into the output parameter data structure, and judge whether there is a URL callback address in the input parameter message header. If there is a URL callback address in the input parameter message header, asynchronously return the status code and the corresponding output parameter message by calling the callback address. If there is no URL callback address, return the result and the output parameter message in a synchronous manner.

5. A method for aggregating RESTful atomic capability interfaces according to claim 1, characterized in that The data in the capability call log table described in S04 includes: capability code, request header, request message, response status code, exception description, response header, response message, call time, and end time.

6. An apparatus for aggregating RESTful atomic capability interfaces, characterized in that, The device includes: A creation module: used to create a RESTful atomic capability information table for filling in and storing the basic information of native atomic capabilities, including: capability code, capability name, request method, capability type, capability URL, request message header, request message, response message header, response message, capability template, authentication code; Aggregation module: It is used to formulate the ability to create programming language rules to create an ability template, and then aggregate multiple native atomic abilities according to the specified logic by using the structure and syntax of the programming language itself to obtain an aggregated ability, and fill in the basic information of the aggregated ability into the RESTful atomic ability information table; Invocation module: It is used to invoke the aggregated ability: judge whether the ability authentication code has a value. If there is no value, this ability does not require authentication; if there is a value, this ability requires authentication, and add the fields and values that need to be authenticated by the authentication code to the authentication information table; judge whether the atomic ability meets the authentication information. If it does not meet, access is refused, and an error code 401 and a prompt for authentication failure are returned; if it meets, parameter verification is performed as required. If the parameter verification fails, an error code 402 and a failure information prompt are returned; if the parameter verification is successful, the input parameter message required by the native atomic ability is assembled, and one or more native atomic abilities are invoked in parallel or serially to obtain the return result; Storage module: It is used to store the aggregated ability call records and the native atomic ability call records into the ability call log table.

7. The apparatus for aggregating a RESTful atomic capability interface according to claim 6, characterized in that, The aggregated ability described in the aggregation module is used as a new ability interface for external system calls or for new aggregation operations within the system.

8. The apparatus for aggregating RESTful atomic capability interfaces according to claim 6, characterized in that, The parameter verification described in the invocation module is used to judge whether any input parameter has a value and whether it meets the corresponding format.

9. The apparatus for aggregating a RESTful atomic capability interface according to claim 6, characterized in that, In the invocation module, if the parameter verification is successful, the input parameter message required by the native atomic ability is assembled, and one or more native atomic abilities are invoked in parallel or serially to obtain the return result. If the native atomic ability call fails, an error code 201 and an error information prompt are returned; If the native atomic ability call is successful, judge its return result. If it does not meet the expected result, other status codes and corresponding prompts are returned according to the interface agreement; if it meets the expected result, set the return status code to 200, and assemble the necessary data into the output parameter data structure, and judge whether there is a URL callback address in the input parameter message header. If there is a URL callback address in the input parameter message header, the status code and the corresponding output parameter data message are asynchronously returned by calling the callback address. If there is no URL callback address, the return result and the output parameter message are returned synchronously.

10. The apparatus for aggregating a RESTful atomic capability interface according to claim 6, characterized in that, The data in the ability call log table described in the storage module includes: ability code, request header, request message, response status code, exception description, response header, response message, call time, and end time.

Images