Http call exception handling method and platform
By dynamically configuring retry strategies and uniformly managing HTTP call exceptions, the resource waste and system instability problems in HTTP call exception handling in existing technologies are solved, enabling rapid problem location and efficient exception handling.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- KANGCHENG INVESTMENT CHINA
- Filing Date
- 2026-01-12
- Publication Date
- 2026-05-26
AI Technical Summary
Existing HTTP call exception handling methods lead to redundant development of functions, waste of resources, scattered exception handling logic, and a lack of unified retry and alarm mechanisms, affecting system stability and fault response speed.
It provides methods and platforms for handling HTTP call exceptions, enabling unified management and exception handling of HTTP interfaces by dynamically configuring retry policies, receiving exception information and initiating automatic or manual retries, and combining them with the alarm mechanism of the monitoring system.
Shorten problem location time, improve R&D efficiency, enhance the stability and fault response speed of distributed systems, reduce system instability issues, and provide a comprehensive call monitoring and alarm mechanism.
Smart Images
Figure CN122093377A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the fields of computer network communication and software middleware, and in particular to an HTTP call exception handling method and platform. Background Technology
[0002] In modern distributed systems, different services typically communicate using the Hypertext Transfer Protocol (HTTP). However, the following abnormal situations often occur during service calls: (1) Network abnormality: HTTP requests fail due to network interruption or instability; (2) Server abnormality: HTTP requests fail due to excessive server load, configuration errors, or program crashes; (3) Timeout error: HTTP requests fail due to excessive request timeout triggering the call timeout mechanism; (4) Custom abnormality: HTTP requests fail due to abnormal business logic or data mismatch.
[0003] Existing exception handling methods are usually developed independently by various R&D teams, which often leads to the following problems: 1) duplicate development of functions, resulting in waste of resources; 2) scattered exception handling logic, making it difficult to manage centrally; 3) lack of a unified retry and alarm mechanism, affecting system stability and fault response speed.
[0004] This paper provides an HTTP exception handling method and platform for use by different R&D teams. It plays an important role in improving R&D efficiency, enhancing the stability of distributed systems, and improving fault response speed. Summary of the Invention
[0005] The technical problem to be solved by this invention is to provide an HTTP call exception handling method and platform that can adapt to different business scenarios, shorten the problem location time, and improve R&D efficiency.
[0006] To address the aforementioned problems, this invention provides an HTTP call exception handling method, comprising: dynamically configuring a retry strategy for HTTP interface calls, wherein the retry strategy includes a retry interval and a maximum number of retries, and the retry strategy can be set individually for different call paths; receiving exception information of HTTP interfaces with call exceptions sent by each caller, wherein the exception information includes the call path and request parameters of the HTTP interface; initiating automatic retries for the HTTP interface according to the retry strategy based on the exception information; issuing an alarm through a monitoring system when the number of automatic retry failures of the HTTP interface reaches the maximum number of retries; and receiving the call path and request parameters of a specific HTTP interface and performing manual retries on them.
[0007] In some embodiments, the retry strategy includes a platform retry strategy and an interface retry strategy. The platform retry strategy is used to perform automatic platform retries on all received HTTP interfaces in batches; the interface retry strategy is used to perform automatic interface retries on a single HTTP interface.
[0008] In some embodiments, the platform retry policy takes effect when the platform automatic retry switch is turned on.
[0009] In some embodiments, the alarm information includes the call path, exception type, request parameters, and number of failures of the HTTP interface. The exception type includes network exception, server exception, timeout error, and custom exception. The method further includes: storing the processing information of the HTTP interface in each step in a database. The processing information includes the caller's callback address, number of retries, retry results, and alarm information.
[0010] In some embodiments, the monitoring system includes a monitoring dashboard, and the method further includes: when the number of automatic retry failures of any HTTP interface reaches the maximum number of retry attempts, displaying the corresponding alarm on the monitoring dashboard.
[0011] In some embodiments, the method further includes: after the HTTP interface has automatically retried or manually retried, returning the retry result to the caller through the caller's callback address.
[0012] In some embodiments, the step of receiving the call path and request parameters of a specific HTTP interface and performing a manual retrieval further includes: A management interface is provided for inputting information about a specific HTTP interface. The interface is used to input information about a specific HTTP interface, and manual retry is performed on the specific HTTP interface according to the interactive instructions of the management interface, and the execution result is returned to the management interface in real time.
[0013] To address the aforementioned issues, this invention also provides an HTTP call exception handling platform, comprising: a configuration management module for dynamically configuring retry strategies for HTTP interface calls, wherein the retry strategy includes a retry interval and a maximum number of retries, and the configuration management module can set retry strategies individually for different call paths; a call receiving module for receiving exception information of HTTP interfaces with call exceptions sent by various callers, wherein the exception information includes the call path and request parameters of the HTTP interface; an automatic retry module for initiating automatic retries of the HTTP interface according to the exception information and the retry strategy; an alarm service module for issuing an alarm through a monitoring system after the number of automatic retry failures of the HTTP interface reaches the maximum number of retries; and a manual retry module for receiving the call path and request parameters of a specific HTTP interface and performing manual retries.
[0014] In some embodiments, a storage module is further included for storing the processing information of the HTTP interface in a database, the processing information including the caller's callback address, the number of retries, the retry result, and alarm information.
[0015] In some embodiments, the alarm service module interfaces with the monitoring system and can push alarm information to the monitoring dashboard of the monitoring system for display, and can support setting alarm priorities according to the anomaly level.
[0016] The above technical solution adapts to different business scenarios by dynamically configuring retry strategies for abnormal calls; it effectively reduces system instability caused by call failures by receiving exception information from various callers regarding HTTP interfaces that have failed to call, and initiating automatic retries for the HTTP interfaces according to the retry strategy; when the number of automatic retry failures of the HTTP interface reaches the maximum number of retries, an alarm is issued through the monitoring system, forming a comprehensive call monitoring and alarm mechanism, shortening the time for locating HTTP interface problems; and it provides call scenarios for problem location by receiving specific HTTP interface call paths and request parameters and performing manual retries, thereby improving location efficiency.
[0017] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit the invention. Techniques, methods, and apparatus known to those skilled in the art may not be discussed in detail, but where appropriate, such techniques, methods, and apparatus should be considered part of the specification. Attached Figure Description
[0018] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0019] Figure 1 This is a flowchart of an HTTP call exception handling method provided in an embodiment of the present invention; Figure 2 This is a schematic diagram of an HTTP call exception handling platform provided in an embodiment of the present invention. Detailed Implementation
[0020] The technical solutions in the embodiments of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0021] The HTTP call exception handling method described in this invention is used to handle HTTP interface calls that fail.
[0022] Figure 1 This is a flowchart of an HTTP call exception handling method provided in an embodiment of the present invention.
[0023] like Figure 1 The HTTP call exception handling method includes: Step S11, dynamically configuring the retry strategy for HTTP interface calls, wherein the retry strategy includes a retry interval and a maximum number of retries, and can set retry strategies individually for different call paths. Step S12, receiving exception information of HTTP interfaces with call exceptions sent by each caller, wherein the exception information includes the call path and request parameters of the HTTP interface; Step S13, initiating automatic retries for the HTTP interface according to the exception information and the retry strategy; Step S14, issuing an alarm through the monitoring system when the number of automatic retry failures of the HTTP interface reaches the maximum number of retries; Step S15, receiving the call path and request parameters of a specific HTTP interface and performing manual retries on it.
[0024] Regarding step S11, the retry strategy for HTTP interface calls is dynamically configured. The retry strategy includes a retry interval and a maximum number of retries, and the retry strategy can be set separately for different call paths.
[0025] The retry strategy includes a platform retry strategy and an interface retry strategy. The platform retry strategy is used to perform automatic platform retries on all received HTTP interfaces in batches. The interface retry strategy is used to perform automatic interface retries on HTTP interfaces individually.
[0026] The retry strategy includes a platform automatic retry switch, which takes effect when the platform automatic retry switch is turned on. In other words, platform automatic retries can only be executed when the platform automatic retry switch is turned on.
[0027] The retry interval refers to the time interval between two automatic retries, and the maximum number of retries is the maximum number of times the same HTTP interface can be retried. Adjusting the retry interval and the maximum number of retries ensures that the HTTP interface test is met while avoiding excessive system load.
[0028] In this embodiment, a visual interface is provided, through which the retry policy can be configured. Alternatively, parameters for the corresponding retry policy can be sent directly via an API interface. The retry policy can be dynamically configured, and modifications take effect immediately without requiring a system restart.
[0029] Furthermore, the configured retry policy is stored in the database, and the database is updated synchronously each time the retry policy is modified.
[0030] Regarding step S12, receive exception information from each caller regarding the HTTP interface that is experiencing a call error. The exception information includes the call path and request parameters of the HTTP interface.
[0031] The caller's callback address is stored in the database for use in replying to messages.
[0032] In this embodiment, each HTTP interface message is configured with an exception handling switch. When the caller fails to call the HTTP interface, the status of the exception handling switch determines whether to use the HTTP call exception handling method for exception handling. Specifically, when the exception handling switch is on, the HTTP call exception handling method of this invention is used for exception handling based on the exception information sent by the caller; when the exception handling switch is off, the caller handles the exception for the HTTP interface.
[0033] The request parameters include the parameter name, parameter type, and parameter value of the HTTP interface. The call path and the request parameters are stored as strings in the exception information.
[0034] The error information includes the complete URL information of the HTTP interface, including the protocol type, domain name, and port, to adapt to different types of servers. In some embodiments, the complete URL is also stored as a string in the error information.
[0035] The exception information also includes exception types, which include network exceptions, server exceptions, timeout errors, and custom exceptions.
[0036] Furthermore, the exception information of the HTTP interface is parsed and the exception information and the parsed information are saved in the database.
[0037] Regarding step S13, based on the exception information, an automatic retry is initiated for the HTTP interface according to the retry strategy.
[0038] Automatic retries include platform-based automatic retries and interface-based automatic retries.
[0039] Platform automatic retries refer to the retrying of HTTP interfaces according to pre-set parameters. Automatic interface retries refer to the retrying of specific HTTP interfaces after receiving exception information from the caller.
[0040] In this embodiment, automatic retries are performed in batches for all received HTTP interfaces according to the platform retry policy; and automatic interface retries are performed individually for each received HTTP interface according to the interface retry policy. Regardless of whether it is platform automatic retries or interface automatic retries, if the result of the HTTP interface retry fails and the number of retries performed on the HTTP interface has not reached the maximum number of retries, then automatic retries continue to be performed.
[0041] Furthermore, after the HTTP interface automatically retryes successfully, the callback address of the caller is retrieved from the database, and the processing result is returned to the caller through the callback address.
[0042] Regarding step S14, when the number of times the HTTP interface fails to automatically retry reaches the maximum number of retries, an alarm is issued through the monitoring system.
[0043] The alarm information includes the HTTP interface call path, exception type, request parameters, and number of failures. The exception type includes network exception, server exception, timeout error, and custom exception.
[0044] The monitoring system includes a monitoring dashboard. When the number of automatic retry failures for any HTTP interface reaches the maximum number of retry attempts, the corresponding alarm is displayed on the monitoring dashboard. Correspondingly, the alarm information is displayed on the monitoring dashboard; furthermore, the alarm information is saved to a database and sent via email to the technical personnel corresponding to the HTTP interface.
[0045] In this embodiment, the monitoring system is a technical dashboard, which is monitored by different technical teams. This allows technical personnel from different teams to promptly identify HTTP interfaces that fail to call, thereby shortening the communication and problem-solving time between teams.
[0046] Regarding step S15, receive the call path and request parameters of the specific HTTP interface and perform a manual retry.
[0047] This step further includes: providing a management interface for inputting information about a specific HTTP interface, which allows manual retrying of the specific HTTP interface based on interactive instructions from the management interface, and returning the execution result to the management interface in real time.
[0048] Technical personnel can manually retries specific HTTP interfaces by configuring relevant parameters and issuing commands through the management interface. This step can be used for interface debugging.
[0049] Furthermore, the results of manual retries are synchronized and updated to the database.
[0050] The above technical solution, through dynamically configuring retry strategies for abnormal calls, receives exception information from each caller regarding abnormal HTTP interface calls and initiates automatic retries for the HTTP interface according to the retry strategy. When the number of automatic retry failures of the HTTP interface reaches the maximum number of retries, an alarm is issued through the monitoring system, forming a comprehensive call monitoring and alarm mechanism, shortening the time for locating HTTP interface problems. By receiving specific HTTP interface call paths and request parameters and performing manual retries, it is used for interface debugging, providing call scenarios for problem location and improving location efficiency.
[0051] Based on the same inventive concept, the present invention also provides an HTTP call exception handling platform.
[0052] Figure 2 This is a schematic diagram of an HTTP call exception handling platform provided in an embodiment of the present invention. Figure 2 As shown, the HTTP call exception handling platform 1 includes a configuration management module 11, a call receiving module 12, an automatic retry module 13, an alarm service module 14, and a manual retry module 15.
[0053] In this embodiment, the system further includes a storage module 16, which is used to store the exception handling information of the HTTP interface in a database.
[0054] In some embodiments, the storage module 16 is a public module other than the HTTP call exception handling platform 1.
[0055] The configuration management module 11 is used to dynamically configure the retry strategy for HTTP interface calls. The retry strategy includes the retry interval and the maximum number of retries. The configuration management module 11 can set the retry strategy separately for different call paths.
[0056] The configuration management module 11 provides a configuration interface for the retry strategy. The retry strategy includes a platform retry strategy and an interface retry strategy. The platform retry strategy is used to perform automatic platform retries on all received HTTP interfaces in batches; the interface retry strategy is used to perform automatic interface retries on individual HTTP interfaces. Configuration interfaces are provided for both the platform retry strategy and the interface retry strategy.
[0057] In this embodiment, the configuration management module 11 includes a visual interface through which the retry strategy can be configured. The visual interface includes a platform automatic retry switch; only when the platform automatic retry switch is enabled can the corresponding strategy parameters for platform automatic retry be configured.
[0058] The retry strategy can be dynamically configured, and changes take effect immediately and are synchronously saved in the database via the storage module 16.
[0059] The call receiving module 12 is used to receive exception information of the HTTP interface sent by each caller, the exception information including the call path and request parameters of the HTTP interface.
[0060] The request parameters include the parameter name, parameter type, and parameter value of the HTTP interface. The call path and the request parameters are stored as strings in the exception information.
[0061] The exception information includes the complete URL information of the HTTP interface, including the protocol type, domain name, and port, to adapt to different types of servers. In some embodiments, the complete URL is stored as a string in the exception information. The exception information also includes the exception type, which includes network exception, server exception, timeout error, and custom exception.
[0062] The abnormal information and its parsed information are stored in the database by the storage module 16.
[0063] The automatic retry module 13 is used to initiate automatic retry of the HTTP interface according to the retry strategy based on the abnormal information.
[0064] The automatic retry module 13 includes a platform automatic retry unit 131 and an interface automatic retry unit 132. The platform automatic retry unit 131 is used to perform automatic retries on all received HTTP interfaces in batches according to the platform retry policy. In this embodiment, each time a platform automatic retry is initiated, the platform automatic retry unit 131 allocates a thread for each HTTP interface in the batch to perform the platform automatic retry.
[0065] The automatic interface retry unit 132 is used to perform automatic interface retries on a received HTTP interface individually according to the interface retry policy. In this embodiment, after the call receiving module 12 receives and parses the exception information of the HTTP interface, the automatic interface retry unit 132 allocates a thread for the HTTP interface to perform automatic interface retries.
[0066] If the automatic retry of the HTTP interface fails, and the number of automatic retries performed by the HTTP interface has not reached the maximum number of retries, then the automatic retry will continue.
[0067] Once the HTTP interface successfully retryes automatically, the callback address of the caller is retrieved from the database, and the processing result is returned to the caller through the callback address.
[0068] The alarm service module 14 is used to issue an alarm through the monitoring system 2 after the number of automatic retry failures of the HTTP interface reaches the maximum number of retry attempts.
[0069] The alarm information includes the HTTP interface call path, exception type, request parameters, and number of failures. The exception type includes network exception, server exception, timeout error, and custom exception.
[0070] The monitoring system 2 includes a monitoring dashboard 21. When the alarm service module 14 detects that the number of automatic retry failures for any HTTP interface has reached the maximum number of retry attempts, it displays the corresponding alarm on the monitoring dashboard 21. Accordingly, the alarm information is displayed on the monitoring dashboard 21.
[0071] The alarm service module 14 is connected to the monitoring system 2 through an interface, and can push alarm information to the monitoring dashboard of the monitoring system 2 for display.
[0072] The alarm service module 14 can set alarm priorities according to the anomaly level.
[0073] Furthermore, the alarm is stored in the database via the storage module 16 and sent to the technical personnel corresponding to the HTTP interface via email.
[0074] In this embodiment, the monitoring system 2 is a technical dashboard for monitoring by different technical teams, enabling technical personnel from different teams to promptly identify HTTP interfaces that fail to call, thereby shortening the communication and problem-solving time between teams.
[0075] The manual retry module 15 is used to receive the call path and request parameters of a specific HTTP interface and perform manual retries. When interface debugging is required, it can be performed through the manual test module 15.
[0076] The manual retry module 15 includes a management interface for inputting information about a specific HTTP interface. It can perform manual retries on the specific HTTP interface according to the interactive instructions of the management interface and return the execution results to the management interface in real time.
[0077] Furthermore, the execution results of manual retries are synchronously updated to the database through the storage module 16.
[0078] The aforementioned HTTP call exception handling platform can be used as middleware by different R&D teams to reduce redundant development and improve R&D efficiency. It can adapt to different business scenarios by dynamically configuring retry strategies. Through automatic retry by the platform and automatic retry by the interface, it can effectively reduce system instability caused by call failure. It can generate alarms for HTTP interfaces that fail to retries multiple times and send them through the monitoring system, forming a complete call monitoring and alarm mechanism, and shortening the time for problem localization.
[0079] It should be noted that references to "an embodiment," "an embodiment," "an exemplary embodiment," "some embodiments," etc., in the specification indicate that the described embodiments may include specific features, structures, or characteristics, but each embodiment may not necessarily include that specific feature, structure, or characteristic. Furthermore, such phrases do not necessarily refer to the same embodiment. In addition, when a specific feature, structure, or characteristic is described in connection with an embodiment, whether explicitly described or not, implementing such a feature, structure, or characteristic in conjunction with other embodiments is within the knowledge of those skilled in the art.
[0080] It should be noted that the terms "comprising" and "having," and their variations, used in this invention document are intended to cover non-exclusive inclusion. The terms "first," "second," etc., are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence, unless explicitly indicated by the context. It should be understood that such data used interchangeably where appropriate. Furthermore, embodiments and features within embodiments of this invention can be combined with each other unless otherwise specified. In addition, descriptions of well-known components and technologies have been omitted in the above description to avoid unnecessarily obscuring the concepts of this invention. In the various embodiments described above, each embodiment focuses on its differences from other embodiments; similar or identical parts between embodiments can be referred to interchangeably.
[0081] The above description is only a preferred embodiment of the present invention. It should be noted that those skilled in the art can make several improvements and modifications without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.
Claims
1. A method for handling HTTP call exceptions, characterized in that, include: The retry strategy for HTTP interface calls is dynamically configured. The retry strategy includes a retry interval and a maximum number of retries, and the retry strategy can be set separately for different call paths. Receive exception information from each caller regarding an HTTP interface that has encountered a call error. The exception information includes the call path and request parameters of the HTTP interface. Based on the error information, an automatic retry is initiated for the HTTP interface according to the retry policy; When the number of automatic retry failures of the HTTP interface reaches the maximum number of retries, an alarm is issued through the monitoring system; It receives the call path and request parameters of a specific HTTP interface and performs manual retries.
2. The HTTP call exception handling method according to claim 1, characterized in that, The retry strategy includes a platform retry strategy and an interface retry strategy. The platform retry strategy is used to perform automatic platform retries on all received HTTP interfaces in batches. The interface retry strategy is used to perform automatic interface retries on a single HTTP interface.
3. The HTTP call exception handling method according to claim 2, characterized in that, The platform retry policy takes effect when the platform's automatic retry switch is turned on.
4. The HTTP call exception handling method according to claim 1, characterized in that, The alarm information includes the call path, exception type, request parameters, and number of failures of the HTTP interface. The exception type includes network exception, server exception, timeout error, and custom exception. The method also includes: saving the processing information of the HTTP interface in each step in a database. The processing information includes the caller's callback address, number of retries, retry results, and alarm information.
5. The HTTP call exception handling method according to claim 1, characterized in that, The monitoring system includes a monitoring dashboard, and the method further includes: when the number of automatic retry failures of any HTTP interface reaches the maximum number of retry attempts, displaying the corresponding alarm on the monitoring dashboard.
6. The HTTP call exception handling platform according to claim 1, characterized in that, The method further includes: after the HTTP interface completes automatic or manual retry, returning the retry result to the caller through the caller's callback address.
7. The HTTP call exception handling method according to claim 1, characterized in that, The steps of receiving the call path and request parameters of a specific HTTP interface and manually retries them further include: A management interface is provided for inputting information about a specific HTTP interface. The interface performs manual retries on the specific HTTP interface according to the interactive instructions of the management interface and returns the execution results to the management interface in real time.
8. An HTTP call exception handling platform, characterized in that, include: The configuration management module is used to dynamically configure the retry strategy for HTTP interface calls. The retry strategy includes the retry interval and the maximum number of retries. The configuration management module can set the retry strategy separately for different call paths. The call receiving module is used to receive exception information of the HTTP interface sent by each caller that the call is abnormal. The exception information includes the call path and request parameters of the HTTP interface. An automatic retry module is used to initiate automatic retries for the HTTP interface according to the retry strategy based on the exception information. The alarm service module is used to issue an alarm through the monitoring system after the number of automatic retry failures of the HTTP interface reaches the maximum number of retry attempts. The manual retry module is used to receive the call path and request parameters of a specific HTTP interface and perform manual retries.
9. The HTTP call exception handling platform according to claim 8, characterized in that, It also includes a storage module for storing the processing information of the HTTP interface in a database. The processing information includes the caller's callback address, the number of retries, the retry results, and alarm information.
10. The HTTP call exception handling platform according to claim 8, characterized in that, The alarm service module interfaces with the monitoring system, enabling it to push alarm information to the monitoring dashboard of the monitoring system for display, and to set alarm priorities according to the anomaly level.