API service management method and device and medium

Abstract

The invention discloses an API service management method and device and a medium, and relates to the technical field of software development. The method comprises the following steps: receiving and verifying API service registration information through a standardized interface to generate service metadata based on the API service registration information, and storing the service metadata to a service directory; wherein the service metadata comprises a service name, an interface address and a version number; when the API calling request arrives at the gateway, performing dual verification on the API calling request; wherein the dual verification comprises calling party identity key authentication and verification of types, ranges and necessary items of request parameters; under the condition that the verification is passed, asymmetrically encrypting and negotiating a session key, and performing symmetric encryption transmission on the request and response data by using the session key; and after the transmission is completed, collecting and calling log data to generate a multi-dimensional monitoring chart, and dynamically adjusting the service priority based on the interface error rate of the service provider.

Description

Technical Field

[0001] The present application relates to the field of software development technology, and in particular to an API service management method, device, and medium. Background Art

[0002] With the widespread adoption of microservices architectures, efficient management and secure invocation of API services have become core requirements for system integration. Existing technologies typically rely on decentralized configuration files and manual maintenance for the registration and management of API services, resulting in a lack of unified standards for service metadata. This can easily lead to issues like interface address conflicts and inconsistent service descriptions during version iterations. Furthermore, the authentication mechanisms of traditional service gateways are often limited to single identity verification and lack the ability to dynamically validate request parameters, making it difficult to effectively intercept malicious requests carrying illegal parameters, posing a significant security risk.

[0003] At the data transmission level, most API management systems use fixed encryption strategies and are unable to dynamically negotiate encryption keys based on session characteristics, making it difficult to balance encryption efficiency and security. Furthermore, existing traffic control solutions are typically based on static threshold settings, lacking real-time feedback on service call quality and unable to dynamically adjust service priorities based on metrics such as interface error rates. This can easily cause high-failure services to continuously occupy system resources, impacting overall service stability.

[0004] Traditional solutions, particularly in high-concurrency scenarios, are less adaptable to burst traffic. They often employ simple request-dropping strategies and lack intelligent queuing mechanisms and hierarchical processing capabilities, leading to frequent misinterpretations of legitimate requests. Service quality monitoring also relies on a single dimension, making it difficult to make service optimization decisions through multi-dimensional data analysis.

[0005] Therefore, how to build an API service management system that takes into account efficient management, dynamic security protection, intelligent traffic scheduling and service quality optimization has become a technical problem that technical personnel in this field urgently need to solve. Summary of the Invention

[0006] The embodiments of the present application provide an API service management method, device, and medium to solve the following technical problem: how to build an API service management system that takes into account efficient management, dynamic security protection, intelligent traffic scheduling, and service quality optimization.

[0007] In the first aspect, an embodiment of the present application provides an API service management method, the method comprising: receiving and verifying API service registration information through a standardized interface to generate service metadata based on the API service registration information, and storing the service metadata in a service directory; wherein the service metadata includes a service name, an interface address, and a version number; when an API call request arrives at the gateway, performing a double verification on the API call request; wherein the double verification includes authentication of the caller's identity key and verification of the type, range, and mandatory items of the request parameters; if the verification passes, using asymmetric encryption to negotiate a session key, and using the session key to perform symmetrical encryption transmission on the request and response data; after the transmission is completed, collecting call log data to generate a multi-dimensional monitoring chart, and dynamically adjusting its service priority based on the service provider's interface error rate.

[0008] In one embodiment of the present application, API service registration information is received and verified through a standardized interface to generate service metadata based on the API service registration information, and the service metadata is stored in a service directory, specifically including: parsing the API description file submitted by the service provider to extract the interface address and service version information in the API description file; verifying the protocol compliance of the interface address and the uniqueness of the version number in the service version information; generating service metadata based on the service name contained in the service version information, the verified interface address and version number, through preset mapping rules; and binding the service metadata to a unique identification code and writing it into the service directory database.

[0009] In one embodiment of the present application, a double verification is performed on the API call request, specifically including: verifying whether the identity identifier and key hash value in the request header of the API call request match the pre-stored credentials; loading the parameter verification rules of the target API from the service directory, performing range checks on the numeric parameters in the API call request, and performing regular expression matching on the string parameters; when it is detected that a required parameter is missing or the parameter type is incorrect, generating a JSON response message containing error details.

[0010] In one embodiment of the present application, the method also includes: when the same caller triggers multiple parameter verification failures within a preset time, its IP is added to a temporary blacklist; subsequent requests from the blacklisted IP are forced to undergo human-machine verification, and access rights are restored after the verification passes.

[0011] In one embodiment of the present application, the method also includes: when the API call request arrives at the gateway, monitoring the API request traffic of the IP corresponding to the API call request in real time, and triggering a dynamic flow limiting strategy based on a preset traffic threshold to queue or discard excess requests, specifically including: when the API call request arrives at the gateway, starting a sliding time window statistics mechanism to monitor the API request traffic of the IP corresponding to the API call request in real time; when it is detected that the number of requests within the sliding time window of the IP corresponding to the API call request exceeds the maximum concurrent connection number preset for the current API service, adding a delay mark to the excess request.

[0012] In one embodiment of the present application, asymmetric encryption is used to negotiate a session key, and the session key is used to perform symmetrical encryption transmission on the request and response data, specifically including: exchanging temporary session keys through an asymmetric encryption algorithm when establishing a communication connection; using the session key to perform AES encryption on the request parameters, and appending an SM3 hash signature to the end of the response data; and performing a decryption operation after verifying the integrity of the hash signature at the receiving end.

[0013] In one embodiment of the present application, call log data is collected to generate a multi-dimensional monitoring chart, and the service priority of the service provider is dynamically adjusted based on the interface error rate of the service provider, specifically including: statistics on the average response time, success rate and error code distribution of the API service to generate a heat map of the geographical distribution of call sources and a peak period traffic trend curve; when the interface error rate of the service provider continuously exceeds the threshold, its ranking weight in the service directory is automatically reduced.

[0014] In one embodiment of the present application, the method further includes: allocating API recommendation resources based on the service provider's historical service quality score; opening a dedicated traffic channel for high-scoring service providers and exempting some flow limiting strategies.

[0015] In a second aspect, an embodiment of the present application also provides an API service management device, the device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute an API service management method such as any one of the above items.

[0016] In a third aspect, an embodiment of the present application further provides a non-volatile computer storage medium for API service management, which stores computer-executable instructions. When the computer-executable instructions are executed, an API service management method such as any one of the above is implemented.

[0017] An API service management method, device and medium provided by the embodiments of the present application have the following beneficial effects: by constructing a standardized service registration system and an intelligent security verification mechanism, refined management of the entire life cycle of API services is achieved. A dynamic security protection system based on double verification effectively intercepts illegal call requests and prevents parameter injection attacks. It combines a hybrid encryption strategy of asymmetric encryption negotiation and national secret algorithms to improve data transmission security while ensuring communication efficiency. Through multi-dimensional monitoring data-driven service quality evaluation, dynamic optimization of service priorities and intelligent resource scheduling are achieved, which not only avoids the continuous occupation of system resources by high-error rate services, but also maintains service stability in burst traffic scenarios through adaptive adjustment of the traffic control algorithm. This method significantly improves the automation level of API management and solves problems such as weak security protection, rigid resource allocation and low operation and maintenance efficiency in traditional solutions. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0019] Figure 1 A flowchart of an API service management method provided in an embodiment of the present application;

[0020] Figure 2 A schematic diagram of the internal structure of an API service management device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0021] To make the purpose, technical solutions, and advantages of this application more clear, the technical solutions of this application will be clearly and completely described below in conjunction with the specific embodiments of this application and the corresponding drawings. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0022] The embodiments of the present application provide an API service management method, device, and medium to solve the following technical problem: how to build an API service management system that takes into account efficient management, dynamic security protection, intelligent traffic scheduling, and service quality optimization.

[0023] The technical solutions proposed in the embodiments of the present application are described in detail below with reference to the accompanying drawings.

[0024] Figure 1 This is a flow chart of an API service management method provided in an embodiment of the present application. Figure 1As shown, an API service management method provided in an embodiment of the present application specifically includes the following steps:

[0025] Step 101: Receive and verify API service registration information through a standardized interface, generate service metadata based on the API service registration information, and store the service metadata in a service directory.

[0026] In this embodiment, the service metadata includes a service name, an interface address, and a version number.

[0027] In one embodiment of the present application, API service registration information is received and verified through a standardized interface to generate service metadata based on the API service registration information, and the service metadata is stored in a service directory, specifically including: parsing the API description file submitted by the service provider to extract the interface address and service version information in the API description file; verifying the protocol compliance of the interface address and the uniqueness of the version number in the service version information; generating service metadata based on the service name contained in the service version information, the verified interface address and version number, through preset mapping rules; and binding the service metadata to a unique identification code and writing it into the service directory database.

[0028] In this embodiment, when the service provider submits API service registration information through a standardized interface (such as a RESTful API), it is necessary to upload a service description file in accordance with the preset JSON Schema format. For example, the service description file contains fields such as the service name, interface address (such as / api / v1 / payment), and version number (such as v1.2.0). It should be noted that the interface address must comply with the HTTP / HTTPS protocol specification, and the version number must follow the semantic version control rules (major.minor.patch format). The built-in version resolution engine will automatically verify the uniqueness of the version number to prevent version conflicts under the same service.

[0029] Specifically, the API description file is structured through the parsing engine. For example, when the service provider submits a YAML file in Swagger format, the path parameters in the interface address (such as / user / {id}) will be extracted and its RESTful design compliance will be verified. It is understandable that if it is detected that the interface address contains illegal characters (such as spaces or special symbols) or the protocol type is missing, an error code (such as 400Invalid URL) will be returned to block the registration process. For the registration information that has passed the verification, service metadata is generated according to the preset mapping rules, such as converting the path hierarchy in the interface address into a service classification label (such as / payment / v1 is mapped to "payment service_V1"), and writing it to the service directory database after binding it with a globally unique service identification code (such as UUID).

[0030] It's important to note that the service catalog utilizes distributed key-value storage (e.g., Etcd) and supports multi-node simultaneous updates. For example, once a service provider completes registration, the gateway monitors the service catalog for change events and loads metadata for newly added services in real time, providing data support for subsequent authentication modules. This process, through standardized registration processes and automated verification mechanisms, ensures the integrity and consistency of service metadata, preventing data errors and omissions caused by manual maintenance.

[0031] Step 102: When the API call request arrives at the gateway, the API call request is double-verified; wherein the double verification includes the caller identity key authentication and the type, range and mandatory item verification of the request parameters.

[0032] In one embodiment of the present application, a double verification is performed on the API call request, specifically including: verifying whether the identity identifier and key hash value in the request header of the API call request match the pre-stored credentials; loading the parameter verification rules of the target API from the service directory, performing range checks on the numeric parameters in the API call request, and performing regular expression matching on the string parameters; when it is detected that a required parameter is missing or the parameter type is incorrect, generating a JSON response message containing error details.

[0033] In one embodiment of the present application, the method also includes: when the same caller triggers multiple parameter verification failures within a preset time, its IP is added to a temporary blacklist; subsequent requests from the blacklisted IP are forced to undergo human-machine verification, and access rights are restored after the verification passes.

[0034] In this embodiment, after the gateway receives the API call request, it first performs the caller identity key authentication. Exemplarily, the identity identifier (such as the globally unique ID assigned by the service provider) and the key hash value (such as the summary of the original key after SHA-256 encryption) are extracted from the request header (such as the X-API-Key field) and matched with the credentials pre-stored in the authorization database (such as the Redis cluster). It should be noted that if the request header does not carry a valid identity identifier or the key hash value is inconsistent with the database record, the gateway will directly return a response containing an error code (such as 401Unauthorized), blocking the subsequent processing flow.

[0035] Specifically, after identity authentication is passed, the parameter verification phase begins. Exemplarily, the gateway loads a preset parameter rule set based on the target API metadata stored in the service directory, including parameter type (such as integer, string), value range (such as the numerical interval [0,10000]) and required item identifier (such as a field marked required:true). For numeric parameters, a dynamic range check is performed (for example, the order amount must meet ≥0); for string parameters, regular expression matching is performed (such as the mobile phone number must conform to the ^1[3-9]\d{9}$ pattern). It is understandable that if a required parameter is detected to be missing or the type does not match, a structured JSON error message (such as {"code":400,"message":"Missing requiredparameter:user_id"}) will be generated and returned directly to the caller through the gateway interceptor.

[0036] It should be noted that when the same caller triggers parameter verification failure multiple times within a preset time (for example, within 5 minutes), its IP address will be automatically added to a temporary blacklist. For example, the gateway records the number of failures of the IP through a distributed counter, and triggers the blacklist mechanism after reaching the threshold. During this period, subsequent requests from the IP are subject to mandatory human-machine verification (such as sliding puzzle verification), and access rights can be restored only after the verification is passed. This mechanism uses Redis's atomic operations (such as INCR and EXPIRE) to achieve accurate counting and status synchronization, which prevents malicious attacks and avoids misjudging legitimate requests.

[0037] Furthermore, the dual verification process is implemented through an asynchronous pipeline architecture, with identity authentication and parameter verification modules executed in parallel, and verification results transmitted via an event bus (such as Kafka). For example, when processing high-concurrency requests, the gateway can distribute identity information and parameter rules to different microservice nodes for processing, significantly improving verification efficiency and system throughput.

[0038] In one embodiment of the present application, the method also includes: when the API call request arrives at the gateway, monitoring the API request traffic of the IP corresponding to the API call request in real time, and triggering a dynamic flow limiting strategy based on a preset traffic threshold to queue or discard excess requests, specifically including: when the API call request arrives at the gateway, starting a sliding time window statistics mechanism to monitor the API request traffic of the IP corresponding to the API call request in real time; when it is detected that the number of requests within the sliding time window of the IP corresponding to the API call request exceeds the maximum concurrent connection number preset for the current API service, adding a delay mark to the excess request.

[0039] In this embodiment, when an API call request arrives at the gateway, the traffic monitoring and control mechanism is triggered in real time. For example, the gateway activates a sliding time window statistics mechanism to dynamically track the request frequency of each caller IP. It should be noted that the sliding time window rolls forward based on the current request time, continuously counting the total number of requests within a preset time period. This design can more accurately reflect instantaneous traffic characteristics and avoid the delay deviation caused by fixed time interval statistics.

[0040] Specifically, the traffic control engine records the request timestamp sequence of each IP through a distributed cache (such as Redis Cluster). For example, when it is detected that the number of requests from a certain IP within the sliding window exceeds the maximum number of concurrent connections of the current API service, a delay mark is automatically added to the excess requests. It is understandable that requests with delay marks will be transferred to the buffer queue, and the queue manager will set different priority weights based on the service level agreement (such as gold / silver service providers) to give priority to high-weight requests.

[0041] It should be noted that the dynamic throttling strategy uses a layered processing mechanism. For example, in burst traffic scenarios, the system first attempts to queue excess requests rather than discarding them directly. When the queue depth reaches the warning threshold, a progressive discard strategy is initiated (e.g., randomly discarding some low-priority requests). This process uses a leaky bucket algorithm to achieve traffic shaping, smoothing out traffic peaks. It also dynamically adjusts the leaky bucket capacity based on the service provider's real-time service quality score, for example, temporarily increasing the throughput quota by 20% for high-scoring service providers.

[0042] Step 103: If the verification is successful, asymmetric encryption is used to negotiate a session key, and the session key is used to perform symmetrical encryption transmission on the request and response data.

[0043] In one embodiment of the present application, asymmetric encryption is used to negotiate a session key, and the session key is used to perform symmetrical encryption transmission on the request and response data, specifically including: exchanging temporary session keys through an asymmetric encryption algorithm when establishing a communication connection; using the session key to perform AES encryption on the request parameters, and appending an SM3 hash signature to the end of the response data; and performing a decryption operation after verifying the integrity of the hash signature at the receiving end.

[0044] In this embodiment, when the API call request passes the double verification, the encrypted communication negotiation process is started. Exemplarily, the client and the server exchange temporary session keys based on the ECDH (Elliptic Curve Diffie-Hellman) algorithm. Specifically, the client first generates a temporary elliptic curve key pair (for example, using the secp256r1 curve), and encrypts the public key with the RSA public key preset by the server and transmits it; after decryption, the server calculates the shared key based on its own private key, and finally both parties independently derive the same session key (such as a 256-bit AES key). It should be noted that this process uses asymmetric encryption to achieve secure key distribution and avoid the risk of plaintext key transmission.

[0045] Specifically, during the data transmission phase, a symmetric encryption algorithm (such as AES-GCM) is used to encrypt the request and response data. For example, after the request parameters are serialized into JSON, they are encrypted using a session key and encapsulated into a ciphertext data packet (such as {"iv":"random vector","ciphertext":"encrypted content"}). An SM3 hash signature is appended to the end of the response data (for example, a 256-bit hash value is calculated for the response body). After decryption, the receiving end recalculates the hash and compares it to ensure data integrity. It can be understood that the combination of asymmetric encryption negotiation keys and symmetric encryption data transmission not only ensures the security of key exchange, but also takes into account the efficiency of large data transmission.

[0046] It's important to note that the SM3 hash algorithm is particularly useful for verifying data tamper resistance in sensitive interfaces, such as payment transactions. For example, when the gateway processes a payment interface response, it generates a hash signature for key fields like the amount and order number. After decryption, the client can verify the signature to see if the data has been tampered with by an intermediary. This mechanism cryptographically binds the request-response relationship, creating an end-to-end secure link.

[0047] Furthermore, the encryption module utilizes a layered design, with the lifecycle of the session key tied to a single API call. For example, the gateway proactively destroys the session key after completing the response transmission and logs key usage via a key management service (such as HashiCorp Vault) to meet audit compliance requirements. This design effectively prevents security risks caused by key reuse and supports dynamic key rotation strategies.

[0048] Step 104: After the transmission is completed, collect call log data to generate a multi-dimensional monitoring chart, and dynamically adjust the service priority of the service provider based on the interface error rate of the service provider.

[0049] In one embodiment of the present application, call log data is collected to generate a multi-dimensional monitoring chart, and the service priority of the service provider is dynamically adjusted based on the interface error rate of the service provider, specifically including: statistics on the average response time, success rate and error code distribution of the API service to generate a heat map of the geographical distribution of call sources and a peak period traffic trend curve; when the interface error rate of the service provider continuously exceeds the threshold, its ranking weight in the service directory is automatically reduced.

[0050] In one embodiment of the present application, the method further includes: allocating API recommendation resources based on the service provider's historical service quality score; opening a dedicated traffic channel for high-scoring service providers and exempting some flow limiting strategies.

[0051] In this embodiment, metadata during the API call process is collected in real time through a log collection agent (such as Filebeat), including information such as response time, status code, and call source IP. For example, the monitoring module aggregates the original log data to generate multi-dimensional analysis charts, such as a heat map of the geographical distribution of call sources (by resolving the geographical location through IP addresses) and a peak-time traffic trend curve (by hourly statistics of request volume). It should be noted that the different color depths in the heat map represent regional request density differences, and operation and maintenance personnel can intuitively identify business hotspots and optimize server resource allocation.

[0052] Specifically, the service quality assessment engine periodically calculates the interface error rate indicators of each service provider. For example, when the error rate of a service provider's payment interface exceeds a preset threshold in three consecutive statistical periods (such as the error response code 5xx accounts for ≥5%), the priority adjustment strategy is automatically triggered. The sorting weight of the service in the service catalog will decrease by a gradient (for example, the initial weight is reduced by 30%), and it will be marked as "degraded state" in the service discovery module, and will be preferentially allocated to other high-availability service nodes during subsequent traffic scheduling. It can be understood that this mechanism achieves flexible allocation of service resources through dynamic weight coefficients (such as the range of 0.1-1.0) to avoid continuous consumption of system resources by low-quality services.

[0053] It should be noted that in this embodiment, recommended position resources are also allocated to service providers with high historical service quality scores. For example, in the "Recommended Services" section of the API portal, service quality scores (such as 0-100 points calculated based on comprehensive response time, success rate, and error rate) are sorted, and service provider interfaces with scores ≥ 90 points are displayed first. In addition, high-scoring service providers can enjoy dedicated traffic channel privileges (such as BGP multi-line bandwidth guarantee) and be exempted from some flow control rules in the traffic control policy (such as allowing their concurrent requests to increase to 150% of the standard value).

[0054] Furthermore, multi-dimensional monitoring data is dynamically displayed through visual dashboards (such as Grafana), supporting drill-down analysis by service version, call time period, and region. For example, when the response time of a service version (such as v1.2.0) suddenly increases, version change records and error logs are automatically linked to help locate performance bottlenecks (such as improper database connection pool configuration). This process uses time-series databases (such as InfluxDB) to store historical indicator data, providing data-driven decision-making for service optimization.

[0055] The above is an embodiment of the method proposed in this application. Based on the same inventive concept, this application embodiment also provides an API service management device, whose structure is as follows Figure 2 shown.

[0056] Figure 2 This is a schematic diagram of the internal structure of an API service management device provided in an embodiment of the present application. Figure 2 As shown, the equipment includes:

[0057] at least one processor 201;

[0058] and, a memory 202 communicatively coupled to the at least one processor;

[0059] The memory 202 stores instructions that can be executed by at least one processor, and the instructions are executed by the at least one processor 201 to enable the at least one processor 201 to:

[0060] Receive and verify API service registration information through a standardized interface to generate service metadata based on the API service registration information, and store the service metadata in the service directory; the service metadata includes the service name, interface address and version number; when the API call request reaches the gateway, the API call request is double-verified; the double verification includes caller identity key authentication and request parameter type, range and mandatory item verification; if the verification passes, asymmetric encryption is used to negotiate the session key, and the session key is used to symmetrically encrypt the request and response data for transmission; after the transmission is completed, the call log data is collected to generate a multi-dimensional monitoring chart, and its service priority is dynamically adjusted based on the service provider's interface error rate.

[0061] Some embodiments of the present application provide corresponding Figure 1 A non-volatile computer storage medium for API service management, storing computer executable instructions, wherein the computer executable instructions are configured to:

[0062] Receive and verify API service registration information through a standardized interface to generate service metadata based on the API service registration information, and store the service metadata in the service directory; the service metadata includes the service name, interface address and version number; when the API call request reaches the gateway, the API call request is double-verified; the double verification includes caller identity key authentication and request parameter type, range and mandatory item verification; if the verification passes, asymmetric encryption is used to negotiate the session key, and the session key is used to symmetrically encrypt the request and response data for transmission; after the transmission is completed, the call log data is collected to generate a multi-dimensional monitoring chart, and its service priority is dynamically adjusted based on the service provider's interface error rate.

[0063] The various embodiments in this application are described in a progressive manner. Similar portions between the various embodiments can be referenced to each other. Each embodiment focuses on the differences from the other embodiments. In particular, the IoT device and media embodiments are generally similar to the method embodiments, so their description is relatively simple. For relevant portions, refer to the description of the method embodiments.

[0064] The system and medium provided in the embodiments of the present application correspond one-to-one to the method. Therefore, the system and medium also have similar beneficial technical effects to their corresponding methods. Since the beneficial technical effects of the method have been described in detail above, the beneficial technical effects of the system and medium will not be repeated here.

[0065] Those skilled in the art will appreciate that the embodiments of the present application can be provided as methods, systems, or computer program products. Therefore, the present application can adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application can adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) that contain computer-usable program code.

[0066] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the steps in the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0067] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0068] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0069] In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

[0070] Memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.

[0071] Computer-readable media includes permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. The information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory computer-readable media (transitory media), such as modulated data signals and carrier waves.

[0072] It should also be noted that the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, commodity, or apparatus that includes a series of elements includes not only those elements but also other elements not explicitly listed, or includes elements inherent to such process, method, commodity, or apparatus. In the absence of further limitations, an element defined by the phrase "comprises a ..." does not exclude the presence of other identical elements in the process, method, commodity, or apparatus that includes the element.

[0073] The foregoing is merely an embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various changes and variations. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application should all be included within the scope of the claims of the present application.

Claims

1. An API service management method, characterized in that: The method comprises: Receive and verify API service registration information through a standardized interface, generate service metadata based on the API service registration information, and store the service metadata in a service directory; wherein the service metadata includes a service name, interface address, and version number; When an API call request reaches the gateway, the API call request is double-verified; wherein the double verification includes the caller's identity key authentication and the type, range and required items of the request parameters; If the verification is successful, asymmetric encryption is used to negotiate the session key, and the session key is used to symmetrically encrypt the request and response data for transmission; After the transmission is completed, the call log data is collected to generate multi-dimensional monitoring charts, and the service priority of the service provider is dynamically adjusted based on the interface error rate of the service provider.

2. The API service management method according to claim 1, characterized in that: Receive and verify API service registration information through a standardized interface, generate service metadata based on the API service registration information, and store the service metadata in the service directory, specifically including: Parse the API description file submitted by the service provider to extract the interface address and service version information in the API description file; Verifying the protocol compliance of the interface address and the uniqueness of the version number in the service version information; Generate the service metadata based on the service name, verified interface address and version number included in the service version information and using a preset mapping rule; The service metadata is bound to the unique identification code and written into the service directory database.

3. The API service management method according to claim 1, characterized in that: Perform double verification on the API call request, specifically including: Verify that the identity and key hash value in the request header of the API call request match the pre-stored credentials; Load the parameter validation rules of the target API from the service catalog, perform range checks on numeric parameters in the API call request, and perform regular expression matching on string parameters; When a required parameter is missing or the parameter type is incorrect, a JSON response message containing error details is generated.

4. The API service management method according to claim 3, characterized in that: The method further comprises: When the same caller fails parameter verification multiple times within a preset time, its IP address will be added to a temporary blacklist. Subsequent requests from blacklisted IP addresses will be subject to mandatory human-machine verification, and access rights will be restored after verification is passed.

5. The API service management method according to claim 1, characterized in that: The method further comprises: When an API call request arrives at the gateway, the API request traffic of the IP address corresponding to the API call request is monitored in real time. Based on the preset traffic threshold, a dynamic flow control strategy is triggered to queue or discard excess requests. Specifically, the strategy includes: When an API call request arrives at the gateway, a sliding time window statistics mechanism is started to monitor the API request traffic of the IP address corresponding to the API call request in real time. When it is detected that the IP corresponding to the API call request has a number of requests within the sliding time window that exceeds the maximum number of concurrent connections preset for the current API service, a delay mark is added to the excess requests.

6. The API service management method according to claim 1, characterized in that: Asymmetric encryption is used to negotiate the session key, and the session key is used to symmetrically encrypt the request and response data for transmission, including: When establishing a communication connection, a temporary session key is exchanged through an asymmetric encryption algorithm; Use the session key to encrypt the request parameters with AES and append an SM3 hash signature to the end of the response data. The receiving end verifies the integrity of the hash signature and then performs the decryption operation.

7. The API service management method according to claim 1, characterized in that: Collect call log data to generate multi-dimensional monitoring charts and dynamically adjust the service priority of service providers based on their interface error rates, including: Collect statistics on the average response time, success rate, and error code distribution of API services to generate a heat map of the geographic distribution of call sources and a traffic trend curve during peak hours. When a service provider's interface error rate continuously exceeds the threshold, its ranking weight in the service directory will be automatically reduced.

8. The API service management method according to claim 1, characterized in that: The method further comprises: Allocate API recommendation resources based on the service provider's historical service quality score; Open dedicated traffic channels for high-rated service providers and exempt them from some traffic limiting strategies.

9. An API service management device, characterized in that: The device comprises: at least one processor; and, a memory communicatively coupled to the at least one processor; The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute an API service management method as described in any one of claims 1-8.

10. A non-volatile computer storage medium for API service management, storing computer-executable instructions, characterized in that: When the computer-executable instructions are executed, an API service management method as described in any one of claims 1 to 8 is implemented.

Images