API full life cycle management method and system based on database management and control

Abstract

The invention provides an API full-life-cycle management method and system based on database management and control. The method comprises the steps that basic information of an API is received through a standardized interface, and the basic information is written into a database after verification is passed; an accessible user role is configured for the registered target API, and the permission association relationship of the target API is written into a database; configuring a read-write attribute, an instance library access rule and a classification permission level of the target API, and writing configuration data into a database; accessing the verified API to a service gateway to open a calling entry; aPI calling data is collected and written into a database, and multi-dimensional analysis is carried out to comprehensively monitor the running state of the API; the system comprises an API registration module, an authority configuration module, an attribute configuration module, an operation monitoring module and a background management module. According to the technical scheme, authority control, attribute configuration and link monitoring are integrated through the centralized database, and the method has important application value.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of API management and permission control, and particularly relates to an API full life cycle management method and system based on database management and control. BACKGROUND

[0002] With the deepening of enterprise digital transformation, the number of application systems within enterprises is increasing, and the integration demand between systems is growing. As a bridge for data interaction and function call between systems, the number and complexity of APIs (Application Programming Interface) are also growing explosively. However, the existing API management method has the following problems:

[0003] Registration management is not standardized: API registration lacks unified standards and processes, resulting in scattered and incomplete API information, making it difficult to effectively find and reuse. Different development teams may use different naming rules and registration methods, making API management and maintenance difficult.

[0004] Permission management is complex: API permission configuration usually requires modifying code or configuration files, which is tedious and prone to errors. When adjusting the access permissions of an API, developers often need to be involved, resulting in delayed permission adjustments and affecting the normal development of business.

[0005] Attribute configuration is not flexible: The read-write attributes, access rules, and other configurations of APIs are usually hard-coded in the code, making it difficult to dynamically adjust according to business needs. When business rules change, code needs to be modified and redeployed, increasing development and maintenance costs.

[0006] Insufficient monitoring and analysis: There is a lack of comprehensive monitoring and analysis of API call conditions, making it difficult to quickly identify performance problems, abnormal calls, and other issues. When an API fails, it is difficult to quickly locate and solve the problem, affecting system stability and usability.

[0007] In summary, the existing API management method cannot meet the needs of efficient and standardized API management in enterprises. Therefore, providing an API management technology that integrates permission management, flexible configuration, full-link monitoring, and centralized database management has become an urgent problem in the industry. SUMMARY

[0008] In view of the above-mentioned deficiencies in the current API management method, the present application provides an API full life cycle management technology based on database management and control to solve the problems of inefficiency and non-standardization in API management in the prior art.

[0009] To achieve the above object, the first aspect of the present application provides an API full life cycle management method based on database management, which comprises:

[0010] API registration: receiving basic information of the API through a standardized interface and writing the basic information into a database after passing the verification;

[0011] Permission configuration: configuring accessible user roles for the registered target API and writing the permission association relationship of the target API into the database;

[0012] Attribute configuration: configuring read-write attributes, instance library access rules and classification permission levels of the target API and writing the configuration data into the database;

[0013] API publishing: performing availability verification on the API which has completed registration, permission configuration and attribute configuration, and connecting the API to a service gateway to open the calling entrance after passing the verification;

[0014] API running monitoring: collecting API calling data and writing the API calling data into the database after passing the verification, and performing multi-dimensional analysis on the API calling data to comprehensively monitor the running state of the API.

[0015] In some embodiments of the first aspect of the present application, during the collection of the API calling data, for the API calling involving data changes, the system synchronously generates a business data change record and writes it into the BussinessHistory table.

[0016] In some embodiments of the first aspect of the present application, the API calling data is multi-dimensional data including caller identity, calling start and end timestamps, API name, calling terminal machine IP and server deployment machine identification;

[0017] The verification includes field non-empty verification, timestamp format verification and data type verification, and the multi-dimensional data is written into the Core_T_ServiceHistory table after passing the verification;

[0018] The multi-dimensional analysis supports real-time analysis and offline analysis, and the analysis content includes calling frequency statistics, calling personnel traceability, processing time consumption analysis, abnormal behavior monitoring and business data change traceability, the abnormal behavior monitoring detects abnormal events in real time by setting single user short time calling frequency threshold and time consumption fluctuation threshold, and the business data change traceability traces the business data modified by a certain API calling by associating the BussinessHistory table through the ServiceHistoryId field of the Core_T_ServiceHistory table.

[0019] In some embodiments of the first aspect of the application, when an abnormal event occurs in the abnormal behavior monitoring process, the access rights of the user related to the abnormal event are locked by modifying the database to achieve security isolation.

[0020] In some embodiments of the first aspect of the application, the receiving of the API basic information through the standardized interface and the writing of the basic information into the database after the verification includes:

[0021] Receiving API basic information through a standardized interface or a visual management tool, the basic information including a unique identifier, a function name, a function description, and an inbound restriction flag;

[0022] Based on the unique identifier, the global uniqueness of the basic data is double-checked;

[0023] After the verification, the basic information is persisted and written into the Security_T_WebApiService table and the API metadata index is updated synchronously.

[0024] In some embodiments of the first aspect of the application, the standardized interface is a RESTful API interface, and the visual management tool is a Web console; the double-checking includes database unique constraint checking and custom query logic checking; the registration method includes single registration and batch registration, and the file format of the batch registration is Excel, JSON, or XML.

[0025] In some embodiments of the first aspect of the application, the configuring of the accessible user roles for the registered target API and the writing of the permission association relationship of the target API into the database table include:

[0026] Obtaining the registered target API through related fields in the basic data;

[0027] Configuring user roles for the target API, the user roles limiting the operation permissions of the target API;

[0028] Detecting the access permissions of the API through a multi-dimensional conflict detection mechanism, and writing the permission association relationship into the Security_T_ServiceRolePermission table after the detection is passed.

[0029] In some embodiments of the first aspect of the application, the related fields are unique identifiers or function names in the basic data; when configuring the user roles for the target API, a single role, multiple associated roles, or a role group can be configured for the target API, and the role group includes multiple roles.

[0030] In some embodiments of the first aspect of the application, the configuring of the read-write attribute, instance library access rule and classification permission level of the target API and writing the configuration relationship into the database table comprises:

[0031] The read-write attribute configuration is performed, and when configuring, the read-write attribute of the API is marked as read-only or writable through a Boolean type;

[0032] The instance library access rule configuration is performed, and when configuring, the instance library identifier of the API is stored through the instance library name field;

[0033] The classification permission level configuration is performed, and when configuring, the permission level of the API is configured as high, medium and low;

[0034] The configuration relationship is written into the Config_T_Config table, and after the configuration is completed, a configuration taking effect event is triggered to make the API calling logic automatically read the new configuration, thereby realizing the hot update of the configuration.

[0035] To achieve the above purpose, the second aspect of the application provides an API full life cycle management system based on database management and control, comprising:

[0036] An API registration module is responsible for realizing the standardized input and standardized storage of API basic information, and providing metadata support for the management of the API life cycle;

[0037] A permission configuration module realizes fine-grained access control by establishing the association relationship between the API and the user role, and eliminates the risk of unauthorized access of the API;

[0038] An attribute configuration module realizes the flexible adjustment of the dynamic attribute of the API, and can adapt to the business changes without code modification;

[0039] A running monitoring module realizes the visual tracking and abnormal early warning of the API calling through full-link data collection and multi-dimensional analysis;

[0040] A background management module provides a central control console for the system, integrates the API full life cycle management, and provides a unified operation entrance and global configuration function.

[0041] The advantages of the embodiment of the present application are as follows: first, the unified registration and management of API are realized through the standardized interface and the visual management end tool, the integrity and consistency of API information are ensured, the searchability and reusability of API are improved; second, the flexible configuration and rapid adjustment of API authority are realized based on the database authority management mechanism, the authority change can be completed without modifying the code, and the efficiency and accuracy of authority management are improved; third, the dynamic configuration of API read-write attributes, instance library access rules and the like is realized by using the configuration table of the database, the change of business rules can be adapted without redeploying the code, and the development and maintenance cost is reduced; fourth, the performance problems and abnormal calls of API are found in time through the comprehensive monitoring and analysis of the running situation of API, strong support is provided for the optimization and problem troubleshooting of API, and the stability and usability of the system are improved; fifth, the repeated labor of the developers is reduced, the development and management efficiency of API is improved, and the process of enterprise digital transformation is accelerated through the provision of batch registration, visual configuration and the like. BRIEF DESCRIPTION OF DRAWINGS

[0042] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the embodiments will be briefly introduced as follows. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor on the basis of these drawings.

[0043] Figure 1 The flowchart of the API full life cycle management method based on database control according to the present application is shown in the figure.

[0044] Figure 2 The API registration flowchart according to the present application is shown in the figure.

[0045] Figure 3 The authority configuration flowchart according to the present application is shown in the figure.

[0046] Figure 4 The attribute configuration flowchart according to the present application is shown in the figure.

[0047] Figure 5 The running monitoring flowchart according to the present application is shown in the figure.

[0048] Figure 6 The structure diagram of the API full life cycle management system based on database control according to the present application is shown in the figure. DETAILED DESCRIPTION

[0049] The technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative work fall within the scope of the present application.

[0050] The technical solutions of the present application relate to the related data of database storage API, including API metadata, role data, permission data, configuration data and API monitoring related data. These data are all structured data. In view of the data model and data scale of the present application, a relational database can be selected for data storage and management in specific implementation, such as MySQL, Oracle, PostgreSQL and other database products. Of course, a database product provided by a cloud vendor can also be used according to actual needs, as long as the requirements of data processing can be met, which all belong to the scope to be protected by the present application.

[0051] For example, Figure 1 The present application shows a flowchart of the API full life cycle management method based on database control, including the following steps:

[0052] Step S1: API registration.

[0053] In the embodiments of the present application, the backend database storage table associated with API registration is Security_T_WebApiService. The table has at least four fields of ServiceId, ServiceName, Description and InboundOnly, which respectively represent the unique identifier, function name, function description and inbound restriction flag of the API.

[0054] When registering, the system receives the basic information of the API, and after verification, writes the information into the API information storage table (Security_T_WebApiService). Figure 2 The specific process of API registration is shown, including the following steps:

[0055] Step S11: receiving API basic information.

[0056] The registration information is received through the standardized interface (such as RESTful API) or management end tool (such as Web console) provided by the system, supporting single API registration information submission through JSON / form or batch import through configuration files in formats such as Excel, JSON, XML, etc. In the embodiments of the present application, the basic information includes unique identifier, function name, function description and inbound restriction flag, etc.

[0057] Step S12: Unique identification double check.

[0058] The embodiment of the application adopts a double check strategy to improve the reliability of the check. Specifically, the database unique constraint (such as the ServiceId field of the Security_T_WebApiService table is set to UNIQUE) and the custom query logic of the related business layer (such as SELECT COUNT(*) FROM Security_T_WebApiService WHERE ServiceId =?) are combined, and the global uniqueness of the unique identification in the basic data is ensured through multiple check means.

[0059] It can be understood that if the check fails (such as the unique identification is repeated), the structured error information (such as {"code": 409, "message": "ServiceId 'API_001' already exists"}) is returned, and the registration process is terminated, thereby ensuring data consistency.

[0060] Step S13: Information persistence and metadata synchronization

[0061] If the check passes, the API basic information is persisted and written into the API information storage table (Security_T_WebApiService) of the database; at the same time, the memory cache (such as Redis cluster) and the search index (such as Elasticsearch) are updated, thereby providing basic metadata support for subsequent permission configuration and call monitoring and ensuring efficient access when configuring and querying permissions.

[0062] Step S2: Permission configuration.

[0063] In the embodiment of the application, the backend database storage table associated with the permission configuration is Security_T_ServiceRolePermission. Through the table, the association relationship between the API and the user role can be constructed.

[0064] As shown in Figure 3 , when configuring permissions, the Security_T_WebApiService table is associated through the ServiceId on the visual interface of the management end to filter the target API, the user role that can access the target API is configured, the permission association relationship is written into the Security_T_ServiceRolePermission table, and the permission check rule is automatically updated and synchronized. Figure 3 The specific process of the permission configuration is shown, including the following steps:

[0065] Step S21: Obtain the registered target API through the related field of the basic data.

[0066] In the embodiments of the present application, the registered target API can be obtained through unique identification or function naming in the basic data. During configuration, the visual interface provided by the management tool is used to accurately filter the target API through the ServiceId (unique identification) field in the Security_T_WebApiServic table; fuzzy search is also supported through the ServiceName (function naming) field, and secondary screening is performed according to the function classification or other difference fields, so as to finally retrieve the target API data to be configured and display on the visual interface.

[0067] Step S22: configuring user roles for the target API.

[0068] During the service period, the API limits the operation permission of the API according to the identity of the caller and the user role bound to the API. When configuring the user roles accessible to the target API, the system provides a flexible role association mechanism, which supports not only individually checking a specific role (such as “finance intern”), but also simultaneously selecting multiple associated roles (such as “finance clerk”, “finance manager” and “audit specialist”), and also enables batch association through the role group function (such as associating the “finance department role group” to the target API as a whole, and all roles in the group will automatically obtain the access permission given to the group).

[0069] During the configuration process, the management tool provided by the system will display the selected role list and the permission range corresponding to the role in real time. For example, when associating roles for the finance query API, it will be explicitly marked that “finance clerk” can only access daily reimbursement data, “finance manager” can access all department financial data, and the selection entry of irrelevant roles such as “human resources role” and “operation and maintenance role” is automatically shielded, thereby avoiding misassociation from the operation level.

[0070] After the configuration is completed, the system automatically generates a role permission list for the management personnel to perform secondary verification, so as to ensure that the associated roles strictly match the business scenarios of the API and block the unauthorized access path of irrelevant roles from the source.

[0071] Step S23: detecting the access permission of the target API through a multi-dimensional conflict detection mechanism, and writing the permission association relationship into the database after the detection is passed.

[0072] Firstly, check whether the role's permission scope matches the API's access requirements. For example, if the target API involves highly sensitive financial data, and the associated role is only a "intern role" with basic query permissions, it is determined that there is a conflict in the permission level. Secondly, check the role's historical association records with the API. If the role has been explicitly prohibited from accessing similar APIs (such as blacklisting rules set due to compliance requirements), a historical rule conflict is triggered. At the same time, verify whether the role's department and the API's business ownership are consistent to avoid cross-department overreach association (such as a sales role associated with a financial-related API).

[0073] If there is a conflict, the system will generate a detailed conflict report, clearly indicating the conflict type (such as permission level mismatch, historical rule conflict) and specific reasons, and providing adjustment suggestions (such as replacing a high-privilege role, removing historical blacklisting restrictions). If there is no conflict, the permission association relationship of unique identifier (ServiceId), role identifier (RoleId), and creation time (CreateTime) will be written into the database through encryption.

[0074] At the same time of writing into the database, through a distributed cache synchronization mechanism (such as Redis publish / subscribe), real-time update the permission verification rules and memory cache of all nodes in the cluster, ensuring that new configurations take effect within a short time (such as 10 seconds) in the whole system, guaranteeing the accuracy of subsequent API call permission verification results.

[0075] Step S3: attribute configuration.

[0076] Using the database configuration table, locate the API's configuration item through the path and configure the API's read / write attributes, instance library access rules, and classification permission levels through the configuration item.

[0077] In the embodiment of the application, the backend database storage table associated with attribute configuration is Config_T_Config. Using this database configuration table, locate the API configuration item through the path, and configure the API's read / write attributes, instance library access rules, and classification permission levels. Figure 4 The specific process of attribute configuration is shown, including the following steps:

[0078] Step S31: read / write attribute configuration. When configuring, mark the API's read / write attributes as read-only or writable through a Boolean type.

[0079] When configuring read-write attributes, the read-write configuration item of the target API can be accurately located through preset path rules. For example, the path format follows " / API / {ServiceId} / Attribute / ReadOnly" to ensure uniqueness. At the same time, the Boolean type parameter is bound with the business scenario depth, such as the order query type API is marked as "read-only (True)" by default to prevent miswriting operation; and the inventory management API is marked as "writable (False)" by default to support real-time updating of inventory quantity.

[0080] After configuration, the system will automatically check the legality of the configuration value. If non-Boolean type data (such as non-False / True text, numbers) is input, an error prompt will be returned immediately and the error field will be highlighted to ensure the legality of the configuration parameter.

[0081] Step S32: Perform instance library access rule configuration. When configuring, store the instance library identifier of the API through the instance library name field.

[0082] When performing instance library access rule configuration, store the specific instance library identifier (such as "ProdDB_Eastern Region" and "TestDB_V2.0") through the instance library name field, and associate the network address, access port, and other basic information of the instance library. At the same time, support preset access rules according to business modules and calling scenarios during configuration, such as setting "when the APP end calls the goods API, access TestDB by default, and when the PC management end calls, access ProdDB".

[0083] After configuration, the system will detect the connectivity of the instance library in real time. If the configured instance library identifier is invalid or cannot be accessed, it will prompt "instance library is not available, please check the identifier or network status" immediately to avoid API calling failure caused by instance library configuration error.

[0084] Step S33: Perform classification permission level configuration. When configuring, configure the permission level of the API as high, medium, and low.

[0085] When performing classification permission level configuration, define the permission level configuration item and associate it with the business sensitivity of the API. When setting "high" permission level, usually associate core business data (such as user payment information and financial core report), and need to bind multiple verification rules (such as requiring secondary identity verification when calling); "medium" permission level corresponds to regular business data (such as goods basic information and order status), suitable for most business scenarios; "low" permission level is for public data (such as enterprise announcements and product introductions), and access restrictions can be relaxed. After configuration, the system will generate a list of permission levels and business scenarios for the administrator to check, ensuring that the level division matches the data sensitivity, such as avoiding missetting the API containing user ID card information as "low" permission level.

[0086] Step S34: Trigger the configuration effective event after the configuration is completed, so that the API calling logic automatically reads the new configuration to realize the hot update of the configuration.

[0087] Specifically, the configuration update can be captured in real time through a database change listening mechanism and synchronized to a distributed memory cache (such as a Redis cluster), so as to ensure that all service nodes in the cluster can obtain the latest configuration within a short time (such as 10 seconds), thereby realizing the hot update of the configuration without restarting the service.

[0088] During the configuration effective process, the system performs configuration consistency verification to compare whether the configuration values stored in the database and the values in the memory cache are consistent, and if there is a difference, a secondary synchronization is automatically initiated; or the system provides a periodic synchronization module to realize the periodic synchronization between the database and the cache.

[0089] At the same time, the log system also records the detailed information of the configuration change, including the changer, the change time, and the configuration content before and after the change, which facilitates subsequent tracing. For example, when the read-write attribute of an API is changed from “read-only” to “writable”, the log will clearly record “2025-07-05 15:30 administrator A changes the read-write attribute of API_001 from True to False”, thereby providing a complete basis for permission audit.

[0090] Step S4: API publishing.

[0091] The API that has completed registration, permission configuration, and attribute configuration can be published online after corresponding checks and tests are passed, and the specific process of API online includes:

[0092] Step S41: Release request receiving and compliance checking.

[0093] The release request containing the identifier of the API to be released and the target environment identifier (such as development environment, test environment, production environment) is received, and the system automatically checks the completeness of the permission configuration (such as whether it is associated with a valid user role), the validity of the attribute parameter (such as whether the read-write attribute meets the business logic), and the connection state of the associated database (to ensure that the target data source can be normally accessed).

[0094] Step S42: Availability verification and state marking.

[0095] The API that passes the compliance check is subjected to availability verification, including interface connectivity detection (verifying whether the API service is normally running), permission rule validity verification (confirming that the role permission configuration can be normally effective), and configuration item effective test (such as whether the instance library access rule is correct). After the verification is passed, the API state is marked as “published”, and the state identifier in the API registration library is updated.

[0096] Step S43: Gateway access and permission opening.

[0097] The API access service gateway is marked as "published" and the calling entry is opened, and at the same time, an access permission opening instruction is sent to the associated database, based on the API permission configuration and attribute parameters, the data resource range accessible in the target environment is accurately configured, and the publishing process is completed.

[0098] Step S5: API running monitoring.

[0099] During the API online service period (from API online to API offline), the running of the API is monitored to observe the service state of the API.

[0100] In the embodiment of the application, the backend database table associated with the API running monitoring is Core_T_ServiceHistory. During the API service period, the system automatically collects multidimensional data and stores it in the Core_T_ServiceHistory table, and the multidimensional data can construct a "digital portrait" of the API calling behavior.

[0101] According to the specific content of the multidimensional data, the Core_T_ServiceHistory table includes at least the following fields:

[0102] ServiceHistoryId: Through the UUID generation algorithm, a unique ID is assigned to each calling record to ensure that the API calling can be traced. Especially in the micro-service mode, when the API calling chain is deep, the same calling process can be traced through the UUID to facilitate problem troubleshooting and positioning;

[0103] CreatedBy: Obtain the caller identity (such as username, user ID) to accurately trace the API caller;

[0104] ServiceStartTime / ServiceEndTime: Record the calling start and end time stamps (accurate to milliseconds) to calculate the processing time (ServiceEndTime-ServiceStartTime);

[0105] ServiceName: Associate the API name in the Security_T_WebApiService table to facilitate API dimension statistical analysis;

[0106] ClientMachine / HostMachine: Collect the calling end machine IP and server deployment machine identification to assist in troubleshooting network and environment related problems.

[0107] Meanwhile, for API calls involving data changes (such as collecting API call data to generate business data change information), the system will synchronously generate business data change records and write them into the BussinessHistory table (stored according to business types, such as BussinessHistory_Order, BussinessHistory_User, etc.), and according to the record content, the BussinessHistory table at least includes the following fields:

[0108] HistoryId: unique identification of business change record;

[0109] ServiceHistoryId: ServiceHistoryId associated with Core_T_ServiceHistory table, realizing the traceability association of call record and data change;

[0110] TableName: business data table name operated;

[0111] OperationType: operation type (such as INSERT, UPDATE, DELETE);

[0112] PrimaryKey: primary key value of the data operated;

[0113] OldValue: value before data change (JSON format);

[0114] NewValue: value after data change (JSON format);

[0115] OperateTime: operation timestamp.

[0116] In the embodiment of the application, according to the collected multi-dimensional data, the system can perform multi-dimensional analysis on the service state of the API and monitor the abnormal behavior therein. Figure 5 The specific process of API operation monitoring in the application is shown, including the following steps:

[0117] Step S51: multi-dimensional data collection and verification.

[0118] When the API is called, a monitoring event is triggered and multi-dimensional data is automatically collected, wherein the multi-dimensional data includes caller identity, call start and end timestamps, API name, calling end machine IP, server deployment machine identification and other key information of API operation state.

[0119] It can be understood that the multi-dimensional data collected needs to be subjected to a series of checking operations such as field non-empty checking, timestamp format checking and data type checking before being written into the Core_T_ServiceHistory table, so as to ensure the integrity and legality of the data.

[0120] Step S52: multi-dimensional analysis processing.

[0121] According to the collected multi-dimensional data, the state of the API can be analyzed in multiple dimensions through the system analysis tool, and these analysis results have important value in the enterprise production environment. In the embodiment of the application, the multi-dimensional analysis specifically includes the following aspects:

[0122] Call frequency statistics: grouped by ServiceName, the number of API calls in a unit of time (hour / day) is counted to identify high / low frequency APIs.

[0123] Call personnel traceability: filtered by CreatedBy, combined with permission rules to investigate irregular operations (such as low-privilege users calling high-sensitive APIs).

[0124] Processing time analysis: calculate the time consumed by a single call, count the time interval proportion, and locate the performance bottleneck (such as complex logic, slow downstream service response) to point out the direction for problem troubleshooting and system performance optimization.

[0125] Abnormal behavior monitoring: set single-user short-time call number threshold and time consumption fluctuation threshold to detect abnormal events (such as malicious attacks, system failures) in real time;

[0126] Business data change tracing: through the association of the ServiceHistoryId of the Core_T_ServiceHistory table with the BussinessHistory system table, it can be traced which business data is modified by a specific API call. When data anomalies occur, the corresponding API call and operator can be quickly located.

[0127] In terms of analysis mode, the technical solution of the application supports multiple analysis modes such as real-time analysis and offline analysis. Among them, real-time analysis can quickly (second level) count the call frequency, processing time, error rate, and identify abnormalities (such as a single user calling more than 100 times in 1 minute) through a stream processing framework (such as Flink); offline analysis can be executed daily through a customized SQL script to generate call trend reports (such as 7-day call volume fluctuation), Top10 API list of time consumption, error type distribution (such as 403 / 500 error proportion) and the like. These analysis data have important value in business analysis and security audit.

[0128] Step S53: presentation and alarm processing of analysis results.

[0129] In the embodiments of the present application, the analysis results can be visually displayed through the dashboard provided by the system, such as displaying a call frequency chart, a Top10 API list, a different type of chart of call failure (response code is not 200), an abnormal event list, etc. through the dashboard.

[0130] Among them, the abnormal behavior in the analysis results can be automatically alarmed by the monitoring module of the system or the externally deployed monitoring system according to the pre-configured alarm rules. At the same time, the system locks the access rights of the user related to the abnormal behavior by modifying the backend database to achieve security isolation. For example, when the monitoring table detects abnormal calling of a role, an operation of temporarily freezing the permissions of the role (writing related fields in Security_T_ServiceRolePermission) is automatically triggered. In this way, with the support of API monitoring metadata, the system can make intelligent decisions in API security, and its response speed is faster and the security protection effect is better than that of traditional technologies.

[0131] If the alarm is implemented through the monitoring module of the system, the monitoring module needs to be constructed. The alarm module can perform real-time data analysis and configure alarm rules. When the alarm rules are triggered, the system automatically extracts alarm-related information (API name involved, triggering time, specific indicator value, violation details), pushes it to the designated recipient according to the configured notification method, and displays the current alarm information of the system on the monitoring dashboard.

[0132] When an externally deployed monitoring system is used, Prometheus can be used to construct the system. At this time, the system needs to provide an API state information collection interface to access the Prometheus monitoring system. At the same time, the alarm rules are defined in the configuration file (such as alert.rules) of Prometheus. When Prometheus continuously pulls the indicators and matches the rules, the alarm information is sent to Alertmanager after the alarm is triggered. Alertmanager performs deduplication, grouping according to the routing rules (such as according to the severity level), and pushes the notification to the designated recipient through email, SMS, enterprise WeChat, etc.

[0133] Step S6: version iteration.

[0134] After the API is completed and put into operation, when the API needs to be updated and upgraded, the original API needs to be iterated. The process of API version iteration includes:

[0135] Step S61: The system receives the update information (JSON format) of the new version API, the update information includes the description of the added function, the modified parameter description and the version number, and generates a new version identifier based on the original unique identifier (ServiceId) and associates the original API information. At the same time, the system can automatically synchronize the basic metadata of the original API to the new version, reducing the repeated configuration workload, and only supplementing or modifying the difference information is needed.

[0136] Step S62: Perform permission configuration and attribute configuration process for the new version API. When configuring, the permission rules and attribute settings of the original version are inherited by default, and targeted adjustment is also supported; if the new test environment needs to be adapted, the instance library access rule can be modified to specify that the new version API accesses the new configuration library instance preferentially.

[0137] Step S63: After the configuration is completed, version compatibility testing is performed, and the testing content includes calling parameter compatibility, return result compatibility, permission inheritance effectiveness and concurrent scene stability. After the test is passed, the new version API is marked as "to be released" state, and the release method can choose "smooth switching" or "gray release" to complete the online. When choosing "smooth switching", the switching time point (usually low peak period) can be set, and the system automatically stops the calling and receiving of the old version API at the time point, switches all traffic to the new version, and keeps the old version instance for a certain period of time as an emergency rollback standby; when choosing "gray release", the traffic can be distributed by proportion or by calling source, and the calling success rate, processing time and other indicators of the new version are monitored in real time. The administrator can gradually increase the traffic proportion according to the monitoring data, and switch to the new version completely after the indicators are stable. During this period, if an abnormality is found, the system can be rolled back to the old version by one key to minimize the release risk.

[0138] Step S7: API offline.

[0139] When the API is no longer used, the offline operation can be initiated on the management end, and the specific process of API offline includes:

[0140] Step S71: Offline application and dependency check.

[0141] The offline request containing the target API identifier and the offline reason is received, the system automatically checks the current calling state (such as active calling, the calling source is displayed) and the dependency relationship (associated user roles, business systems) of the API, and feeds back the check result to the administrator, waiting for confirmation whether to continue the offline process.

[0142] Step S72: Buffer period warning and state transition.

[0143] After the administrator confirms the offline, the API state is marked as "to be offline", the offline pre-warning notice is sent to the associated user roles and business systems, and a preset buffer period (countdown) is set. Normal calls are allowed within the buffer period, but the offline pre-warning information is returned automatically when called, reminding the calling party to adapt in advance.

[0144] Step S73: formal offline and data archiving.

[0145] After the buffer period ends, the API state is updated to "offline", the calling entry is removed from the service gateway, all permission records of the API in the permission configuration library are deleted and access to the associated database is prohibited; at the same time, the registration information, configuration records, calling history and other data of the API are archived to the historical storage area of the database.

[0146] Figure 6 The structure diagram of the API full life cycle management system based on database control in an embodiment of the present application is shown. As can be seen from the figure, the system 100 of the present application includes an API registration module 101, a permission configuration module 102, an attribute configuration module 103, a running monitoring module 104 and a background management module 105.

[0147] The API registration module 101 is responsible for realizing the standardized input and standardized storage of API basic information, and providing metadata support for subsequent management processes. When the API is registered, the registration process of steps S11 to S13 is executed.

[0148] The permission configuration module 102 realizes fine-grained access control by establishing the association between the API and the user role, and eliminates the risk of unauthorized access of the API. When the permission is configured, the permission configuration process of steps S21 to S23 is executed.

[0149] The attribute configuration module 103 realizes flexible adjustment of API dynamic attributes without code modification to adapt to business changes. When the attribute is configured, the attribute configuration process of steps S31 to S34 is executed.

[0150] The running monitoring module 104 realizes visual tracking and abnormal early warning of API calling through full-link data collection and multi-dimensional analysis. When the API is online, the running monitoring module executes the running monitoring process of steps S51 to S53.

[0151] The background management module 105 serves as the central control console of the system, integrates the full life cycle management of the API, and provides a unified operation entry and global configuration function, and its functions include:

[0152] Whole process visual management: the operation interface of integrating API registration, permission configuration, attribute configuration, release, version iteration, and offline functions, supports one-stop query of the whole life cycle state of API and the configuration of associated data through a unique identifier (ServiceId).

[0153] Batch operation and template management: provides batch registration templates, permission configuration templates, and attribute configuration templates, supports one-key export of API list, configuration records, and monitoring reports, reduces repeated operations.

[0154] System parameter configuration: allows administrators to set global rules, such as API unique identifier naming specification, permission conflict detection threshold, monitoring data retention period, alarm recipient grouping, and notification method and channel of the recipient.

[0155] Log audit and permission control: records all operation logs, supports retrieval by operation type and time range; limits the operation permissions of different roles through administrator role grading, ensures system operation compliance.

[0156] The advantages of the implementation of the present application are as follows: first, through standardized interfaces and visual management tools, unified registration and management of APIs are realized, ensuring the integrity and consistency of API information, improving the findability and reusability of APIs; second, based on a database-based permission management mechanism, flexible configuration and rapid adjustment of API permissions are realized, without the need to modify the code to complete permission changes, improving the efficiency and accuracy of permission management; third, using database configuration tables, dynamic configuration of API read-write attributes, instance library access rules, and other functions is realized, without the need to redeploy the code to adapt to changes in business rules, reducing development and maintenance costs; fourth, through comprehensive monitoring and analysis of API running conditions, performance problems and abnormal calls of APIs are discovered in a timely manner, providing strong support for API optimization and problem troubleshooting, improving the stability and usability of the system; fifth, through the provision of batch registration, visual configuration, and other functions, the repetitive work of developers is reduced, the development and management efficiency of APIs is improved, and the process of enterprise digital transformation is accelerated. In summary, the present application realizes efficient and standardized management of the whole life cycle of APIs through a database-based control method, and has important application value in enterprise production environments.

[0157] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto, any skilled person in the art can easily think of changes or replacements within the scope of the disclosed technology, which should be covered within the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

Claims

1. A method for API life cycle management based on database management, characterized in that, The API full life cycle management method based on database management includes the following steps: API registration: receiving basic information of the API through a standardized interface and writing the basic information into the database after passing the verification; Permission configuration: configuring accessible user roles for the registered target API and writing the permission association relationship of the target API into the database; Attribute configuration: configuring read-write attributes, instance library access rules, and classification permission levels of the target API and writing the configuration data into the database; API publishing: performing availability verification on the API that has completed registration, permission configuration, and attribute configuration, and connecting the API to the service gateway to open the calling entrance after passing the verification; API running monitoring: collecting API calling data and writing the API calling data into the database after passing the verification, and performing multi-dimensional analysis on the API calling data to comprehensively monitor the running state of the API.

2. The database management-based API full life cycle management method of claim 1, wherein, During the collection of API calling data, for API calls involving data changes, the system synchronously generates business data change records and writes them into the BussinessHistory table. 3.The database management-based API full life cycle management method of claim 2, wherein, The API calling data is multi-dimensional data including caller identity, calling start and end timestamps, API name, calling end machine IP, and service end deployment machine identifier; The verification includes field non-empty verification, timestamp format verification, and data type verification, and after passing the verification, the multi-dimensional data is written into the Core_T_ServiceHistory table; The multi-dimensional analysis supports real-time analysis and offline analysis, and the analysis content includes calling frequency statistics, calling personnel traceability, processing time consumption analysis, abnormal behavior monitoring, and business data change traceability. The abnormal behavior monitoring detects abnormal events in real time by setting single-user short-time calling frequency threshold and time consumption fluctuation threshold. The business data change traceability traces the business data modified by a certain API call by associating the ServiceHistoryId field of the Core_T_ServiceHistory table with the BussinessHistory table.

4. The database management-based API full life cycle management method of claim 3, wherein, When an abnormal event occurs in the abnormal behavior monitoring process, the access rights of the user related to the abnormal event are locked by modifying the database to achieve security isolation.

5. The database pipeline-based API lifecycle management method of claim 1, wherein, The method of receiving basic information of the API through a standardized interface and writing the basic information into the database after passing the verification includes: Receiving API basic information through a standardized interface or a visual management tool, the basic information including unique identifier, function name, function description, and input restriction marker; Based on the unique identifier, double-check the global uniqueness of the basic data; After passing the verification, persistently write the basic information into the Security_T_WebApiService table and synchronously update the API metadata index.

6. The database pipeline-based API lifecycle management method of claim 5, wherein, The standardized interface is a RESTful API interface, and the visualization management tool is a Web console; the double verification includes database unique constraint verification and custom query logic verification; the registration mode includes single registration and batch registration, and the file format of the batch registration is Excel, JSON or XML.

7. The database pipeline-based API lifecycle management method of claim 1, wherein, The target API is configured with an accessible user role after registration, and the permission association relationship of the target API is written into a database table, including: Obtaining the registered target API through related fields in the basic data; The target API is configured with a user role, which limits the operation permission of the target API; Through a multi-dimensional conflict detection mechanism, the access permission of the API is detected, and after the detection is passed, the permission association relationship is written into the Security_T_ServiceRolePermission table. 8.The database management-based API life cycle management method of claim 7, wherein, The related fields are unique identifiers or function names in the basic data; when the target API is configured with a user role, the target API can be configured with a single role, multiple associated roles or a role group, and the role group includes multiple roles.

9. The database pipeline-based API lifecycle management method according to any one of claims 1 to 8, characterized in that, The read-write attribute, instance library access rule and classification permission level of the target API are configured, and the configuration relationship is written into a database table, including: Read-write attribute configuration, when configuring, mark the read-write attribute of the API as read-only or writable through a Boolean type; Instance library access rule configuration, when configuring, store the instance library identifier of the API through the instance library name field; Classification permission level configuration, when configuring, configure the permission level of the API as high, medium and low; Write the configuration relationship into the Config_T_Config table, and after the configuration is completed, trigger the configuration effective event to make the API calling logic automatically read the new configuration to realize the hot update of the configuration.

10. A database management-based API full life cycle management system, characterized in that, The API full life cycle management system (100) based on database management and control includes: An API registration module (101) is responsible for realizing standardized input and standardized storage of API basic information, and providing metadata support for management of API life cycle; A permission configuration module (102) realizes fine-grained access control by establishing the association relationship between the API and the user role, and eliminates the risk of unauthorized access of the API; An attribute configuration module (103) realizes flexible adjustment of dynamic attributes of the API without code modification to adapt to business changes; A running monitoring module (104) realizes visual tracking and abnormal early warning of API calling through full-link data collection and multi-dimensional analysis; A background management module (105) provides a central control console for the system, integrates API full life cycle management, and provides a unified operation entrance and global configuration function.

Images