CN120994640A - API full life cycle management method and system based on database management and control - Google Patents

Abstract

The invention provides an API full life cycle management method and system based on database management, the method comprises the steps of receiving basic information of an API through a standardized interface and writing the basic information into a database after verification is passed, configuring accessible user roles for a registered target API and writing authority association relations of the target API into the database, configuring read-write attributes, instance library access rules and classification authority grades of the target API and writing configuration data into the database, accessing the verified API into a service gateway to open a call entrance, collecting API call data and writing the API call data into the database, and performing multidimensional analysis to realize full monitoring on the running state of the API. The technical scheme of the invention integrates authority management and control, attribute configuration and link monitoring through the centralized database, and has important application value.

Description

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

Technical Field

The invention relates to the technical field of API management and authority control, in particular to an API full life cycle management method and system based on database management and control.

Background

With the deep digital transformation of enterprises, the number of application systems in the enterprises is continuously increased, and the integration demands among the systems are increasing. The number and complexity of APIs (Application Programming Interface, application programming interfaces) that bridge inter-system data interactions and function calls has also grown explosively. However, the existing API management method has the following problems:

Registration management is not standard, and API registration lacks unified standard and flow, so that API information is scattered and incomplete, and effective searching and multiplexing are difficult to perform. Different development teams may use different naming rules and registration schemes, making management and maintenance of APIs difficult.

The authority management is complex, the authority configuration of the API usually needs to modify codes or configuration files, and the operation is complex and easy to make mistakes. When the access rights of the API are required to be adjusted, the intervention of a developer is often required, so that the rights are not adjusted timely, and the normal development of the service is influenced.

The attribute configuration is inflexible, namely, the configuration such as the read-write attribute, the access rule and the like of the API are usually hard-coded in codes, and are difficult to dynamically adjust according to service requirements. When business rules change, the codes need to be modified and redeployed, increasing development and maintenance costs.

The monitoring analysis is insufficient, namely the comprehensive monitoring and analysis on the calling condition of the API are lacking, and the conditions of performance problems, abnormal calling and the like of the API cannot be found in time. When an API fails, it is difficult to quickly locate and solve the problem, affecting the stability and usability of the system.

In summary, the existing API management method cannot meet the requirements of enterprises for efficient and standard management of APIs. Therefore, providing an API management technology integrating rights management, flexible configuration, full link monitoring, and centralized database management is a problem to be solved in the industry.

Disclosure of Invention

In view of the above-mentioned shortcomings of the existing API management methods, the present invention provides a full life cycle management technique of an API based on database management, which is used to solve the problems of inefficiency and non-standardization in the API management in the prior art.

To achieve the above object, a first aspect of the present invention provides an API full life cycle management method based on database management, including:

the method comprises the steps of API registration, namely receiving basic information of an API through a standardized interface and writing the basic information into a database after verification is passed;

configuring accessible user roles for the registered target APIs and writing the authority association relation of the target APIs into a database;

configuring read-write attributes of the target API, access rules of the instance library and classification authority levels, and writing configuration data into a database;

the API release comprises the steps of carrying out availability check on the API which completes registration, authority configuration and attribute configuration, and accessing the API into a service gateway to open a call entry after the verification is passed;

and the API operation monitoring is to collect API call data and write the API call data into a database after passing verification, and carry out multidimensional analysis on the API call data so as to realize comprehensive monitoring on the operation state of the API.

In some embodiments of the first aspect of the present application, during the collection of API call data, the system may contemporaneously generate a business data change record and write to the BussinessHistory series of tables for the API call involving the data change.

In some embodiments of the first aspect of the present application, the API call data is multidimensional data including caller identification, call start-stop timestamp, API name, calling end machine IP, and service end deployment machine identification;

the verification comprises field non-null verification, time stamp format verification and data type verification, and after the verification is passed, the multidimensional data is written into a core_T_ ServiceHistory table;

The multi-dimensional analysis supports real-time analysis and offline analysis, analysis content comprises calling frequency statistics, calling personnel tracing, time-consuming analysis processing, abnormal behavior monitoring and service data change tracing, the abnormal behavior monitoring is used for detecting abnormal events in real time by setting a single user short-time calling frequency threshold and a time-consuming fluctuation threshold, and the service data change tracing is used for tracing service data modified by an API call through the association of the BussinessHistory series list in ServiceHistoryId fields of the core_T_ ServiceHistory table.

In some embodiments of the first aspect of the present application, when an abnormal event occurs during the abnormal behavior monitoring process, the access authority of the user related to the abnormal event is locked by modifying the database to realize security isolation.

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

receiving API basic information through a standardized interface or a visual management end tool, wherein the basic information comprises a unique identifier, a function naming, a function description and an incoming limit mark;

double checking is carried out on the global uniqueness of the basic data based on the unique identification;

And after the verification is passed, the basic information is permanently written into a security_T_ WebApiService table and the API metadata index is synchronously updated.

In some embodiments of the first aspect of the present application, the standardized interface is a RESTful API interface, the visual management end tool is a Web console, the dual check includes a database unique constraint check and a custom query logic check, the registration mode includes a single registration and a batch registration, and the file format of the batch registration is Excel, JSON or XML.

In some embodiments of the first aspect of the present application, the configuring the accessible user roles for the registered target API and writing the authority association relationship of the target API into the database table includes:

acquiring a registered target API through relevant fields in the basic data;

configuring a user role for the target API, wherein the user role defines the operation authority of the target API;

And detecting the access rights of the API through a multi-dimensional conflict detection mechanism, and writing the rights association relationship into a security_T_ ServiceRolePermission table after the access rights pass the detection.

In some embodiments of the first aspect of the present application, the relevant field is a unique identifier or function name in the base data, and when configuring the user role for the target API, a single role, multiple associated roles, or a role group may be configured for the target API, where the role group includes multiple roles.

In some embodiments of the first aspect of the present application, the configuring the read-write attribute, the instance library access rule, and the classification authority level of the target API and writing the configuration relationship into the database table includes:

Performing read-write attribute configuration, wherein the read-write attribute through the Boolean type mark API is read-only or writable during configuration;

performing instance library access rule configuration, and storing an instance library identifier of an API through an instance library name field during configuration;

classifying authority level configuration is carried out, and the authority level of the API is configured to be high, medium and low during configuration;

and writing the configuration relation into a configuration_T_Config table, and triggering a configuration validation event after the configuration is completed, so that the API call logic automatically reads the new configuration to realize the hot update of the configuration.

To achieve the above object, a second aspect of the present invention provides an API full lifecycle management system based on database management, the API full lifecycle management system based on database management including:

the API registration module is responsible for realizing standardized input and standardized storage of API basic information and providing metadata support for management of an API life cycle;

The authority configuration module realizes fine-granularity access control by establishing the association relation between the API and the user role, and avoids the risk of unauthorized access of the API;

The attribute configuration module realizes flexible adjustment of the dynamic attribute of the API and can adapt to service change without code modification;

the operation monitoring module realizes the visual tracking and abnormal early warning of the API call through full-link data acquisition and multidimensional analysis;

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

The method has the advantages that firstly, unified registration and management of the API are realized through a standardized interface and a visual management end tool, the integrity and consistency of API information are ensured, the searchability and reusability of the API are improved, secondly, flexible configuration and quick adjustment of the API authority are realized based on an authority management mechanism of a database, the authority change can be completed without modifying codes, the efficiency and accuracy of the authority management are improved, thirdly, the dynamic configuration of the API read-write attribute, the instance library access rule and the like is realized by utilizing a configuration table of the database, the change of the business rule can be adapted without redeploying codes, the development and maintenance cost is reduced, fourthly, the performance problem and abnormal call of the API are timely found through comprehensive monitoring and analysis of the running condition of the API, the stability and the usability of the system are improved, and the repeated labor of developers is reduced, the development and management efficiency of the API is improved, and the digitalized conversion process of enterprises is accelerated by providing functions such as batch registration and visual configuration.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings that are needed in the embodiments will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

FIG. 1 is a flowchart of an API full life cycle management method based on database management according to the present invention;

FIG. 2 is a schematic diagram of an API registration process according to the present invention;

FIG. 3 is a schematic diagram of a rights configuration flow according to the present invention;

FIG. 4 is a schematic diagram of an attribute configuration flow according to the present invention;

FIG. 5 is a schematic diagram of an operation monitoring flow according to the present invention;

fig. 6 is a schematic structural diagram of an API full life cycle management system based on database management according to the present invention.

Detailed Description

The following description of the embodiments of the present invention will be made clearly and completely with reference to the accompanying drawings, in which it is apparent that the embodiments described are only some embodiments of the present invention, but not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the invention without making any inventive effort, are intended to be within the scope of the invention.

The technical scheme of the application relates to the related data of a database storage API, which comprises API metadata, role data, authority data, configuration data and API monitoring related data. In view of the data model and the data scale of the application, the data can be stored and managed by using a relational database, such as MySQL, oracle, postgreSQL, and the database product provided by a cloud provider can be used according to actual needs, so long as the requirements of data processing can be met.

FIG. 1 shows a flowchart of the database management-based API full life cycle management method of the present application, comprising the steps of:

And S1, API registration.

In the embodiment of the present invention, the backend database storage table associated with the API registration is security_t_ WebApiService. The table has at least SERVICEID, SERVICENAME, DESCRIPTION and InboundOnly fields that represent the unique identification of the API, function naming, function description, and inbound restriction flags, respectively.

When registering, the system receives basic information of the API, and after verification passes, the information is permanently written into an API information storage table (security_T_ WebApiService). Fig. 2 illustrates a specific process of API registration, comprising the steps of:

and S11, receiving the API basic information.

Registration information is received through a standardized interface (e.g., RESTfulAPI) or a management end tool (e.g., web console) provided by the system, supporting submission of single API registration information through JSON/forms, or batch importation of configuration files in a format such as Excel, JSON, XML. In the embodiment of the invention, the basic information comprises a unique identifier, a function name, a function description, an incoming limit mark and the like.

And S12, carrying out double verification on the unique identification.

The embodiment of the invention adopts a double verification strategy to improve the verification reliability. Specifically, a method of combining a UNIQUE constraint of a database (for example, the ServiceId field of the security_t_ WebApiService table is set to UNIQUE) with a custom query logic of a related service layer (for example, SELECT COUNT (x) FROM security_t_ WebApiService WHERE SERVICEID =.

It will be appreciated that if the verification fails (e.g., the unique identifier is repeated), structured error information (e.g., { "code":409, "message": "ServiceId 'api_001' already exists" }) is returned, and the registration flow is terminated, ensuring data consistency.

Step S13 synchronization of information persistence and metadata

If the verification is passed, the API basic information is permanently written into an API information storage table (security_T_ WebApiService) of the database, and a memory cache (such as a Redis cluster) and a search index (such as an elastic search) are updated at the same time, so that basic metadata support is provided for subsequent authority configuration and call monitoring, and efficient access during authority configuration and call query is ensured.

And S2, configuring the authority.

In the embodiment of the invention, the storage table of the back-end database associated with the authority configuration is security_T_ ServiceRolePermission. Through the table, the association relationship between the API and the user roles can be constructed.

As shown in fig. 3, in the authority configuration, a security_t_ WebApiService table is associated on a visual interface of a management end through ServiceId to screen a target API, and after a user role accessible to the target API is configured, the authority association relationship is written into the security_t_ ServiceRolePermission table, and the authority verification rule is automatically updated synchronously. Fig. 3 shows a specific process of rights configuration, comprising the steps of:

and S21, acquiring the registered target API through the relevant fields of the basic data.

In the embodiment of the invention, the acquisition of the registered target API can be realized through unique identification or function naming in the basic data. During configuration, a visual interface provided by a management end tool is used for precisely screening target APIs through a ServiceID field in a security_T_ WebApiServic table, fuzzy search is also supported through SERVICENAME (function naming) fields, secondary screening is carried out according to function classification or other difference fields, and therefore target APIs data to be configured are finally retrieved and displayed on the visual interface.

And S22, configuring a user role for the target API.

During service, the API defines the operating rights of the API according to the identity of the caller and the user role bound to the API. When configuring accessible user roles for a target API, the system provides a flexible role association mechanism, which not only supports the independent selection of a specific role (such as a financial intern), but also allows the simultaneous selection of a plurality of associated roles (such as a financial special person, a financial manager and an audit special person), and can realize batch association through role group functions (such as the overall association of the financial role group to the target API, all roles in the group automatically obtain the access rights given to the group).

In the configuration process, a management end tool provided by the system can display a selected role list and a permission range corresponding to the role in real time, for example, when the role is associated with a financial inquiry API, a financial staff can be clearly marked to only access daily reimbursement class data, a financial manager can access all gate financial data, and meanwhile, the selection entrance of irrelevant roles such as a human resource role, an operation and maintenance role and the like is automatically shielded, so that the false association is avoided from an operation level.

After the configuration is completed, the system automatically generates a role authority list for a manager to check secondarily, ensures that the associated roles are strictly matched with the service scene of the API, and blocks unauthorized access paths of irrelevant roles from the source.

And S23, detecting the access rights of the target API through a multidimensional conflict detection mechanism, and writing the rights association relation into a database after the detection is passed.

Firstly checking whether the authority range of the role is matched with the access requirement of the API, for example, when the target API relates to high-sensitivity financial data, judging that the authority level conflicts if the associated role is a 'training role' only provided with basic query authorities, secondly checking the historical association record of the role and the API, triggering the historical rule conflicts if the role is explicitly forbidden to access the similar API (such as a blacklist rule set by the compliance requirement), and simultaneously verifying whether the business attributions of the department to which the role belongs and the API are consistent or not so as to avoid cross-department override association (such as selling the API related to the role association financial).

If there is a conflict, the system will generate a detailed conflict report, and explicitly annotate the conflict type (such as permission level mismatch, history rule conflict) and specific reasons, and provide adjustment advice (such as replacing with high permission role, removing history blacklist limitation), if there is no conflict, the permission association relation of unique identification (ServiceId), role identification (RoleId) and creation time (CreateTime) is written into the database by encryption.

When the database is written, the authority check rules and the memory caches of all nodes in the cluster are updated in real time through a distributed cache synchronization mechanism (such as Redis publishing and subscribing), so that the full system effect of the new configuration in a short time (such as 10 seconds) is ensured, and the accuracy of the authority check results of the subsequent API calls is ensured.

And S3, configuring attributes.

And positioning the configuration items of the API through the path by utilizing the database configuration table, and configuring the read-write attribute, the instance library access rule and the classification authority level of the API through the configuration items.

In the embodiment of the invention, the storage table of the back-end database associated with attribute configuration is Config_T_Config. And using the database configuration table to configure the read-write attribute, the instance library access rule and the classification authority level of the API through path positioning of the API configuration item. Fig. 4 illustrates a specific process of attribute configuration, including the steps of:

And S31, configuring the read-write attribute, wherein the read-write attribute of the mark API is read-only or writable through the Boolean type during configuration.

When the read-write attribute configuration is carried out, the read-write configuration item of the target API can be accurately positioned through a preset path rule. For example, the path format follows "/API/{ Serviceid }/Attribute/ReadOnly" to ensure uniqueness. Meanwhile, the Boolean type parameter is deeply bound with the business scene, for example, an order inquiry API is marked as read-only (True) by default to prevent misoperation operation, and an inventory management API is marked as writable by default to support real-time update of inventory quantity.

After configuration, the system will automatically check the validity of the configuration value, if non-boolean data (such as non-False/True text, numbers) is input, the system immediately returns a format error prompt and highlights the error field, so as to ensure the validity of the configuration parameters.

And S32, configuring an instance library access rule, and storing an instance library identifier of the API through an instance library name field during configuration.

When the instance library access rule configuration is carried out, specific instance library identifications (such as 'ProdDB _eastern area', 'TestDB _v2.0') are stored through an instance library name field, and basic information such as a network address, an access port and the like of the instance library are associated. Meanwhile, the access rule is preset according to the service module and the calling scene in the configuration process, for example, the default access to the TestDB when the APP terminal calls the commodity API is set, and the access is ProdDB when the PC management terminal calls.

After configuration, the system can detect the connectivity of the instance library in real time, and if the configured instance library identification is invalid or cannot be accessed, the system can prompt that the instance library is unavailable, please check the identification or the network state, so that the API call failure caused by the instance library configuration error is avoided.

And step S33, classifying authority level configuration, wherein the authority level of the API is configured to be high, medium and low during configuration.

When classifying authority level configuration is carried out, an authority level configuration item is defined and strongly correlated with the service sensitivity degree of the API. When setting the high authority level, the core business data (such as user payment information and financial core report) is usually associated, multiple verification rules (such as secondary identity verification when calling) are required to be additionally bound, the medium authority level corresponds to the conventional business data (such as commodity basic information and order status) and is suitable for most business scenes, and the low authority level can relax access restriction for public data (such as enterprise bulletin and product introduction). After configuration, the system generates a corresponding list of authority levels and service scenes for an administrator to check, so as to ensure that the level division is matched with the data sensitivity, for example, avoid setting the API containing the user identity card information to be a low authority level by mistake.

And step S34, triggering a configuration validation event after the configuration is completed, so that the API call logic automatically reads the new configuration to realize the hot update of the configuration.

The configuration update can be captured in real time through a database change monitoring mechanism and synchronized to a distributed memory cache (such as a Redis cluster), so that all service nodes in the cluster can acquire the latest configuration in a short time (such as 10 seconds), and the configuration hot update can be realized without restarting the service.

In the configuration validation process, the system can perform configuration consistency check to compare whether the configuration value stored in the database is consistent with the value in the memory cache, and if the configuration value is different from the value in the memory cache, secondary synchronization is automatically initiated, or the system provides a periodic synchronization module to realize periodic synchronization between the databases such as the caches.

Meanwhile, the log system also records the detailed information of configuration change, including the change person, change time and configuration content before and after the change, so that the subsequent traceability is facilitated. For example, when the read-write attribute of an API is changed from "read-only" to "writable", the log clearly records that the administrator A changes the read-write attribute of the API_001 from True to False "in order to provide a complete basis for authority audit.

And S4, releasing the API.

The API which completes registration, authority configuration and attribute configuration can be released to be online after corresponding inspection and test are carried out and pass through the inspection and test, and the specific process of the online of the API comprises the following steps:

Step S41, request receiving and compliance checking are issued.

Receiving a release request containing an API identifier to be released and a target environment identifier (such as a development environment, a test environment and a production environment), automatically checking authority configuration integrity (such as whether a valid user role is associated), attribute parameter validity (such as whether a read-write attribute accords with business logic) and an associated database connection state (ensuring that a target data source can be normally accessed) by a system.

And S42, checking availability and marking state.

Availability checks are performed on APIs that pass compliance checks, including interface connectivity checks (to verify if the API service is running properly), rights rule validity checks (to confirm that role rights configuration can be validated properly), and configuration item validation tests (e.g., if the instance library access rules are correct). After the verification is passed, the API state is marked as published, and the state identification in the API registry is updated.

Step S43, gateway access and authority are opened.

And (3) marking the API with the state of released to be accessed to a service gateway, opening a call entry, simultaneously sending an access right opening instruction to an associated database, and accurately configuring the accessible data resource range in a target environment based on the right configuration and attribute parameters of the API to finish the release process.

And S5, monitoring the operation of the API.

During an API online service (from API online to API offline), the running of the API is under monitoring to observe the service state of the API.

In the embodiment of the invention, the back-end database table associated with the API operation monitoring is core_T_ ServiceHistory. During API service, the system automatically collects multidimensional data that can construct a "digital representation" of the behavior of API calls and stores the multidimensional data in the core_T_ ServiceHistory table.

The core_t_ ServiceHistory table includes at least the following fields according to the specific contents of the multidimensional data:

ServiceHistoryId, distributing unique IDs for each call record through a UUID generation algorithm, and ensuring the traceability of the call of the API. Especially in the micro-service mode, when the call chain of the API is deeper, the same call process can be traced back through the UUID so as to facilitate the investigation and positioning of the problem;

CreatedBy obtaining caller identification (such as user name and user ID) for precisely tracing back the API caller;

SERVICESTARTTIME/SERVICEENDTIME, record call start and stop time stamps (accurate to milliseconds) for computing processing time consuming (SERVICEENDTIME-SERVICESTARTTIME);

SERVICENAME associating API names in the security_T_ WebApiService table so as to be statistically analyzed according to the dimension of the API;

CLIENTMACHINE/HostMachine, collecting calling end machine IP and service end machine identification, which are used for assisting in checking network and environment related problems.

Meanwhile, for the API call related to data change (such as collecting the service data change information generated by the API call data), the system will generate the service data change record simultaneously, write BussinessHistory series list (stored according to the service type list, such as BussinessHistory _ Order, bussinessHistory _user, etc.), and according to the record content, bussinessHistory series list includes at least the following fields:

HistoryId unique identifiers of service change records;

ServiceHistoryId, serviceHistoryId of the associated core_T_ ServiceHistory table, which realizes the traceability association of the calling record and the data change;

TableName the name of the operated business data table;

OperationType type of operation (e.g., INSERT, UPDATE, DELETE);

PRIMARYKEY a primary key value of the operated data;

OldValue values before data change (JSON format);

NewValue values after data change (JSON format);

OperateTime operation time stamp.

According to the embodiment of the application, the system can carry out multidimensional analysis on the service state of the API and monitor the abnormal behavior in the service state according to the collected multidimensional data. FIG. 5 illustrates a specific process for API operation monitoring in the present application, comprising the steps of:

And S51, multi-dimensional data acquisition and verification.

When the API is called, a monitoring event is triggered and multidimensional data is automatically collected, wherein the multidimensional data comprises key information of the running states of the API such as caller identification, calling start-stop time stamp, API name, calling end machine IP, service end machine identification and the like.

It will be appreciated that the collected multidimensional data requires some column check operations such as field non-empty check, time stamp format check, and data type check before writing into the core_t_ ServiceHistory table to ensure the integrity and validity of the data.

And S52, multidimensional analysis processing.

According to the collected multidimensional data, the state of the API can be subjected to multidimensional analysis through a system analysis tool, and analysis results have important values in the enterprise production environment. In the embodiment of the invention, the multidimensional analysis specifically comprises the following aspects:

and counting calling frequency, namely counting the calling times of each API in unit time (hours/day) according to SERVICENAME groups, and identifying the high-frequency/low-frequency APIs.

And (3) calling personnel trace, namely screening according to CreatedBy, and checking illegal operations in combination with authority rules (such as calling a high-sensitivity API by a low-authority user).

And (3) processing time consumption analysis, namely calculating single call time consumption, counting the time consumption interval proportion, positioning performance bottlenecks (such as complex logic and slow downstream service response), and indicating a direction for problem investigation and system performance optimization.

Abnormal behavior monitoring, namely setting a single user short-time calling time threshold value and a time-consuming fluctuation threshold value to detect abnormal events (such as malicious attacks and system faults) in real time;

Service data change tracing, namely tracing back which service data are specifically modified by an API call through a ServiceHistoryId associated BussinessHistory series list of the core_T_ ServiceHistory list, and rapidly positioning corresponding API calls and operators when data abnormality occurs.

In the analysis mode, the technical scheme of the application supports multiple analysis modes such as real-time analysis, off-line analysis and the like. The real-time analysis can rapidly (second-level) count calling frequency, process time consumption, error rate, identify abnormality (such as calling more than 100 times within 1 minute of a single user) and the like through a stream processing framework (such as a Flink), and the offline analysis can be executed regularly every day through a customized SQL script to generate a calling trend report (such as fluctuation of the calling quantity of near 7 days), a time-consuming Top10 API list, error type distribution (such as 403/500 error duty ratio) and the like. These analytical data are of great value in both business analysis and security auditing.

And step S53, the analysis result is presented and the alarm is processed.

In the embodiment of the invention, the analysis result can be visually displayed through a billboard provided by the system, such as a statistical chart of calling times, a time-consuming Top10 API list, a statistical chart of different types of calling failures (response codes are not 200), an abnormal event list and the like.

The abnormal behavior in the analysis result can be automatically sent out to be notified by a monitoring module of the system or an externally deployed monitoring system according to a preset warning rule. Meanwhile, the system locks the access authority of the user related to the abnormal behavior in a mode of modifying the back-end database so as to realize safety isolation. Such as when the monitoring table detects an abnormal call to a character, an operation to temporarily freeze the authority of the character (write the relevant field in security_t_ ServiceRolePermission) is automatically triggered. Therefore, through supporting of the API monitoring metadata, the system can make intelligent decisions in the aspect of API safety, and compared with the traditional technology, the system has the advantages of higher response speed and better safety protection effect.

If the alarm is realized through a 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 (related API names, trigger time, specific index values and violation details), and the alarm related information is pushed to a designated receiver according to a configured notification mode, and meanwhile, the current alarm information of the system can be displayed on a monitoring billboard.

When an externally deployed monitoring system is employed, the system may be constructed using Prometaus, at which point the system needs to provide an API status information acquisition interface to access the Prometaus monitoring system. Meanwhile, an alarm rule is defined in a configuration file (such as alert, rules), when the alert is continuously pulled and matched with the rule, alarm information is sent to ALERTMANAGER after the alarm is triggered, ALERTMANAGER performs de-duplication and grouping according to a routing rule (such as a level of security), and a notification is pushed to a designated receiver in a mode of mail, short message, enterprise WeChat and the like.

And S6, version iteration.

After the API is online, when the API needs to be subjected to function updating and version upgrading, the original API needs to be iterated, and the process of the iteration of the version of the API comprises the following steps:

Step S61, the system receives update information (JSON format) of the new version API, wherein the update information comprises a newly added function description, a modified parameter description and a version number, and generates a new version identifier based on an original unique identifier (Serviceid) and associates the original API information. Meanwhile, the system can automatically synchronize the basic metadata of the original API to the new version, reduce the repeated configuration workload and only need to supplement or modify the difference information.

And step S62, executing authority configuration and attribute configuration flow on the API of the new version. And if a new test environment needs to be adapted, the instance library access rule can be modified, and the new version API can be appointed to access the new configuration library instance preferentially.

And step 63, performing version compatibility test after configuration is completed, wherein the test contents comprise call parameter compatibility, returned result compatibility, permission inheritance validity and concurrent scene stability. After the test is passed, marking the API with new version as a state to be released, and the releasing mode can be selected to finish the online in a smooth switching or gray level releasing mode. When selecting 'gray level release', supporting to distribute flow according to proportion or calling source, monitoring indexes such as calling success rate and time consumption of new version in real time, the manager can gradually increase flow ratio according to monitoring data, and completely switch to new version after the index is stable, and can roll back to old version by one key to reduce release risk to the greatest extent if abnormality is found in the period.

And S7, the API is disconnected.

When the API is not used any more, the offline operation can be initiated at the management end, and the specific process of the offline operation of the API comprises the following steps:

Step S71, off-line application and dependency check.

And receiving a downloading request containing the target API identifier and the downloading reason, automatically checking the current calling state of the API (showing a calling source if active calling exists) and the dependency relationship (associated user roles and service systems) by the system, feeding back the checking result to an administrator, and waiting for confirmation of whether to continue the downloading process.

And step S72, early warning in a buffer period and state transition.

After confirming offline, the administrator marks the API state as 'offline waiting', sends offline early warning notification to the associated user roles and the service system, and sets a preset buffer period (countdown). Normal calling is allowed in the buffering period, but off-line early warning information is automatically returned during calling, and a calling party is reminded of adapting in advance.

And step 73, formally downloading and archiving the data.

After the buffering period is finished, the API state is updated to be 'off line', a call entry is removed from a service gateway, all authority records of the API in the authority configuration library are deleted, access to an associated database is forbidden, and meanwhile registration information, configuration records, call history and other data of the API are archived in a history storage area of the database.

FIG. 6 is a schematic diagram of an API full lifecycle management system based on database management in accordance with an embodiment of the present application. As can be seen, the system 100 of the present application includes an API registration module 101, a rights configuration module 102, an attribute configuration module 103, an operation monitoring module 104, and a background management module 105.

The API registration module 101 is responsible for realizing standardized input and standardized storage of API basic information and providing metadata support for subsequent management processes. The registration process of steps S11 to S13 is performed at the time of API registration.

The authority configuration module 102 realizes fine-granularity access control by establishing the association relation between the API and the user role, and avoids the risk of unauthorized access of the API. The rights configuration process is performed as in the above steps S21 to S23.

The attribute configuration module 103 realizes flexible adjustment of the dynamic attribute of the API, and can adapt to service change without code modification. The attribute configuration process is performed as in the above steps S31 to S34.

The operation monitoring module 104 realizes the visual tracking and the abnormal early warning of the API call through full-link data acquisition and multidimensional analysis. When the API is in the online service, the operation monitoring performs the operation monitoring flow of steps S51 to S53 described above.

The background management module 105 serves as a central console of the system, integrates full lifecycle management of APIs, and provides unified operation entry and global configuration functions, including:

and the whole-flow visual management comprises integrating operation interfaces of functions such as API registration, authority configuration, attribute configuration, release, version iteration, offline and the like, and supporting the configuration of the whole life cycle state and associated data of the one-stop query API through a unique identifier (ServiceId).

Batch operation and template management, namely providing batch registration templates, authority configuration templates, attribute configuration templates and the like, supporting one-key export of an API list, configuration records and monitoring report forms, and reducing repeated operation.

And (3) configuring system parameters, namely allowing an administrator to set global rules, such as API unique identification naming standards, authority conflict detection thresholds, monitoring data retention periods, alarm receiver grouping, receiver notification modes, channel passing and the like.

Log audit and authority control, namely recording all operation logs, supporting retrieval according to operation types and time ranges, limiting the operation authorities of different roles through role classification of an administrator, and ensuring the operation compliance of the system.

The method has the advantages that firstly, unified registration and management of the API are realized through a standardized interface and a visual management end tool, the integrity and consistency of API information are ensured, the searchability and reusability of the API are improved, secondly, flexible configuration and quick adjustment of the API authority are realized based on an authority management mechanism of a database, the authority change can be completed without modifying codes, the efficiency and accuracy of the authority management are improved, thirdly, the dynamic configuration of the API read-write attribute, the instance library access rule and the like is realized by utilizing a configuration table of the database, the change of the business rule can be adapted without redeploying codes, the development and maintenance cost is reduced, fourthly, the performance problem and abnormal call of the API are timely found through comprehensive monitoring and analysis of the running condition of the API, the stability and the usability of the system are improved, and the repeated labor of developers is reduced, the development and management efficiency of the API is improved, and the digitalized conversion process of enterprises is accelerated by providing functions such as batch registration and visual configuration. In a word, the method realizes the efficient and standard management of the full life cycle of the API by a database management and control mode, and has important application value in the enterprise production environment.

The foregoing is merely illustrative of the present invention, and the present invention is not limited thereto, and any changes or substitutions easily contemplated by those skilled in the art within the technical scope of the present invention should be included in the scope of the present invention. Therefore, the protection scope of the present invention shall be subject to the protection scope of the claims.

Claims (10)

1. A database-controlled API lifecycle management method, characterized in that the database-controlled API lifecycle management method includes the following steps: API registration: Receive basic API information through a standardized interface and write the basic information into the database after successful verification; Permission configuration: Configure the user roles that can access the target API after registration and write the permission association relationship of the target API into the database; Attribute configuration: Configure the read and write attributes, instance library access rules, and category permission levels of the target API and write the configuration data to the database; API Release: Perform availability verification on APIs that have completed registration, permission configuration, and attribute configuration. Once the verification is successful, connect the API to the service gateway to open the call entry point. API operation monitoring: Collect API call data and write the API call data into the database after verification. Perform multi-dimensional analysis on the API call data to achieve comprehensive monitoring of the API's operation status. 2. The API lifecycle management method based on database control according to claim 1, characterized in that, during the collection of API call data, for API calls involving data changes, the system will synchronously generate business data change records and write them into the BusinessHistory series table. 3. The API lifecycle management method based on database control according to claim 2, wherein the API call data is multi-dimensional data including caller identity identifier, call start and end timestamps, API name, caller machine IP, and server deployment machine identifier; The verification includes field non-empty verification, timestamp format verification, and data type verification. After the verification is passed, the multidimensional data is written to the Core_T_ServiceHistory table. The multi-dimensional analysis supports both real-time and offline analysis. The analysis content includes call frequency statistics, caller tracing, processing time analysis, abnormal behavior monitoring, and business data change tracing. The abnormal behavior monitoring detects abnormal events in real time by setting thresholds for the number of calls per user in a short period and thresholds for time fluctuations. The business data change tracing traces the business data modified by a certain API call by associating the ServiceHistoryId field of the Core_T_ServiceHistory table with the BusinessHistory series tables. 4. The API lifecycle management method based on database control according to claim 3, characterized in that, when an abnormal event occurs during the abnormal behavior monitoring process, the access permissions of users related to the abnormal event are locked by modifying the database to achieve security isolation. 5. The API lifecycle management method based on database control according to claim 1, characterized in that, receiving basic API information through a standardized interface and writing the basic information into the database after verification includes: Receive basic API information through standardized interfaces or visual management tools. The basic information includes a unique identifier, function name, function description, and inbound restriction flags. The global uniqueness of the basic data is double-checked based on the unique identifier; After successful verification, the basic information is persisted to the Security_T_WebApiService table and the API metadata index is updated synchronously. 6. The API lifecycle management method based on database control according to claim 5, characterized in that the standardized interface is a RESTful API interface, the visual management tool is a Web console; the dual verification includes database unique constraint verification and custom query logic verification; the registration method includes single registration and batch registration, and the file format of the batch registration is Excel, JSON or XML. 7. The API lifecycle management method based on database control according to claim 1, characterized in that, configuring accessible user roles for the registered target API and writing the permission association relationship of the target API into the database table includes: The registered target API can be obtained by using the relevant fields in the basic data; Configure user roles for the target API, and the user roles limit the operation permissions of the target API; Access permissions to the API are checked through a multi-dimensional conflict detection mechanism. Once the detection is successful, the permission association is written to the Security_T_ServiceRolePermission table. 8. The API lifecycle management method based on database control according to claim 7, wherein the relevant fields are unique identifiers or function names in the basic data; when configuring user roles for the target API, a single role, multiple associated roles, or role groups can be configured for the target API, and the role group includes multiple roles. 9. The API lifecycle management method based on database control according to any one of claims 1 to 8, characterized in that configuring the read/write attributes, instance library access rules, and classification permission levels of the target API and writing the configuration relationship into the database table includes: Configure read/write attributes, and use a boolean type to mark the API's read/write attributes as read-only or writable; Configure instance library access rules, storing the instance library identifier of the API through the instance library name field during configuration; Configure the permission levels for different categories, setting the API permission levels to high, medium, and low. The configuration relationship is written to the Config_T_Config table. After the configuration is completed, a configuration effect event is triggered, which enables the API call logic to automatically read the new configuration, thereby realizing hot update of the configuration. 10. A database-managed API lifecycle management system, characterized in that the database-managed API lifecycle management system (100) comprises: The API registration module (101) is responsible for the standardized entry and storage of basic API information, providing metadata support for the management of the API lifecycle. The permission configuration module (102) establishes a relationship between API and user roles to achieve fine-grained access control and eliminate the risk of unauthorized access to APIs. The attribute configuration module (103) enables flexible adjustment of API dynamic attributes, allowing for adaptation to business changes without code modification; The monitoring module (104) enables visualized tracking and anomaly warning of API calls through full-link data collection and multi-dimensional analysis; The backend management module (105) provides a central console for the system, integrates API lifecycle management, and provides a unified operation entry and global configuration function.