Network request method and device based on abstract thinking, storage medium and equipment

Abstract

The application relates to the technical field of data processing and financial technology, and discloses a network request method and device based on abstract thinking, a storage medium and computer equipment, the method is applied to an intermediate layer, the intermediate layer comprises a service provider and a service builder, and the method comprises the following steps: defining an application layer interface of an application layer based on an interface declaration specification of the intermediate layer, and obtaining a business interface of the application layer by inheriting an abstract base class interface of the intermediate layer from the application layer interface; the service provider receives an original network request sent by the application layer through any business interface of the business interface, the original network request comprises a business interface instance and request parameters; the service provider performs assembly processing on the business interface instance and the request parameters to obtain a request object; the service builder determines a target execution layer according to a server address in the request parameters, performs packaging processing on the request object to obtain a network request matched with an interface specification of the target execution layer, and sends the network request to the target execution layer for network request processing.

Description

Technical Field

[0001] This application relates to the fields of data processing and financial technology, and in particular to a network request method, apparatus, storage medium and computer equipment based on abstract thinking. Background Technology

[0002] In the fintech field, most widely used open-source network frameworks are directly integrated with the underlying network request functions of the system or browser (such as the axios library or the native request interface of mini-programs). These frameworks have complex implementation mechanisms and provide numerous APIs and configuration options. However, the implementation and calling methods of network interfaces differ significantly between different platforms (such as H5, mini-programs, and native apps). Therefore, many fintech projects have to customize the network layer for each platform.

[0003] Fintech applications heavily rely on third-party network framework interfaces to make network requests. Differences in implementation between different frameworks or even different versions of the same framework significantly hinder the flexibility of application layers when upgrading frameworks or switching to other network request products. This dependency and inconsistency increase the difficulty of future technological iterations and optimizations of fintech systems. For example, in the fintech field, there is a growing demand for cross-platform (e.g., H5, mini-programs, apps) and intra-platform cross-application (e.g., different financial projects A and B) development. However, due to the inconsistency of network framework interfaces across platforms and applications, developers need to spend additional time and effort adapting to and learning different network request implementations. This not only increases development costs but also extends project delivery cycles.

[0004] The fintech sector faces numerous challenges and issues when leveraging existing open-source network frameworks. To address these challenges, a more unified, flexible, and maintainable solution for network requests needs to be explored. Summary of the Invention

[0005] In view of this, embodiments of this application provide a network request method, apparatus, storage medium, and computer device based on abstract thinking, which can realize unified network request processing across platforms and applications, reduce development and maintenance costs, and improve the scalability and maintainability of the system.

[0006] According to one aspect of this application, a network request method based on abstract thinking is provided, applied to a middleware layer, the middleware layer including a service provider and a service builder, the method comprising:

[0007] The application layer interface is defined based on the interface declaration specification of the middle layer, and the application layer interface is obtained by inheriting the abstract base class interface of the middle layer.

[0008] The service provider receives a raw network request sent by the application layer through any of the business interfaces, wherein the raw network request includes a business interface instance and request parameters;

[0009] The service provider assembles the business interface instance and the request parameters to obtain a request object;

[0010] The service builder determines the target execution layer based on the server address in the request parameters, packages the request object to obtain a network request that matches the interface specification of the target execution layer, and sends it to the target execution layer for network request processing.

[0011] Optionally, in this embodiment, the intermediate layer further includes a first slice plugin; after the service provider assembles the business interface instance and the request parameters to obtain a request object, the method further includes:

[0012] The first slice plugin takes the request object as a request instance, obtains the public parameter information corresponding to the request instance, and encapsulates the public parameter information into the request instance to obtain a new request instance. The public parameter information includes a user login status token.

[0013] The first slice plugin passes the new request instance to the service builder;

[0014] Accordingly, the service builder determines the target execution layer based on the server address in the request parameters, and packages the request object to obtain a network request that matches the interface specification of the target execution layer, including:

[0015] The service builder determines the target execution layer based on the server address in the new request instance, and packages the new request instance to obtain a network request that matches the interface specification of the target execution layer.

[0016] Optionally, in this embodiment of the application, the step of wrapping the new request instance to obtain a network request that matches the interface specification of the target execution layer includes:

[0017] The service builder injects the dependency information required by the target execution layer into the new request instance, and packages the request address, response data type, request method, request type and request header in the request instance after the dependency information is injected, so as to obtain a network request that matches the interface specification of the target execution layer.

[0018] Optionally, in this embodiment of the application, after sending the request to the target execution layer for network request processing, the method further includes:

[0019] The service provider receives the response data returned by the target execution layer, processes the response data into a response body, and sends the response body to the business interface.

[0020] Optionally, in this embodiment of the application, the intermediate layer further includes a second slice plugin; the step of processing the response data into a response body and sending the response body to the service interface includes:

[0021] The service provider transmits the response data to the second slice plugin;

[0022] The second slice plugin parses the response data, determines the response status code, response result, request address, and request type of the response data, determines whether the network request was successful based on the response status code, and determines the corresponding target application layer based on the request address when the request is successful. It then performs format conversion on the response result to obtain a response body that conforms to the requirements of the target application layer, and sends the response body to the service provider.

[0023] The service provider sends the response body to the business interface in the target application layer that matches the request type, so that the target application layer obtains the response body corresponding to the original network request.

[0024] Optionally, in this embodiment of the application, after determining whether the network request was successful based on the response status code, the method further includes:

[0025] When the second slice plugin determines that the request has failed, it generates response failure information corresponding to the response data based on the failure reason indicated by the response status code, and sends the response failure information to the service provider.

[0026] The service provider sends the response failure information to the target execution layer.

[0027] Optionally, in this embodiment, the intermediate layer further includes a statistician; the method further includes:

[0028] Based on the parsing results of the response data returned by each execution layer, determine the request success rate corresponding to each execution layer and the reason for request failure corresponding to request failure;

[0029] The system analyzes the reasons for request failures at each execution layer and, based on the frequency of occurrence of different reasons, identifies high-frequency and occasional reasons for request failures. It then sends the corresponding request success rate, frequency of occurrence of each reason for request failure, high-frequency and occasional reasons for request failure to the management terminal corresponding to each execution layer.

[0030] According to another aspect of this application, a network request apparatus based on abstract thinking is provided, applied to an intermediate layer, the intermediate layer including a service provider and a service builder, the apparatus comprising:

[0031] The application layer definition module is used to define the application layer interface of the application layer based on the interface declaration specification of the middle layer, and to obtain the business interface of the application layer by inheriting the abstract base class interface of the middle layer.

[0032] The request receiving module is used by the service provider to receive the original network request sent by the application layer through any of the business interfaces in the business interfaces, wherein the original network request includes a business interface instance and request parameters;

[0033] The request processing module is used by the service provider to assemble the business interface instance and the request parameters to obtain a request object; the service builder determines the target execution layer based on the server address in the request parameters, and packages the request object to obtain a network request that matches the interface specification of the target execution layer.

[0034] The request sending module is used to send requests to the target execution layer for network request processing.

[0035] Optionally, in this embodiment of the application, the intermediate layer further includes a first slice plugin; the request processing module is further configured to:

[0036] After the service provider assembles the business interface instance and the request parameters to obtain a request object, the first slice plugin takes the request object as a request instance, obtains the public parameter information corresponding to the request instance, and encapsulates the public parameter information into the request instance to obtain a new request instance. The public parameter information includes a user login status token.

[0037] The first slice plugin passes the new request instance to the service builder;

[0038] The service builder determines the target execution layer based on the server address in the new request instance, and packages the new request instance to obtain a network request that matches the interface specification of the target execution layer.

[0039] Optionally, in this embodiment of the application, the request processing module is further configured to:

[0040] The service builder injects the dependency information required by the target execution layer into the new request instance, and packages the request address, response data type, request method, request type and request header in the request instance after the dependency information is injected, so as to obtain a network request that matches the interface specification of the target execution layer.

[0041] Optionally, in this embodiment, the apparatus further includes a response processing module, configured to:

[0042] The service provider receives the response data returned by the target execution layer, processes the response data into a response body, and sends the response body to the business interface.

[0043] Optionally, in this embodiment, the intermediate layer further includes a second slice plugin; the response processing module is further configured to:

[0044] The service provider transmits the response data to the second slice plugin;

[0045] The second slice plugin parses the response data, determines the response status code, response result, request address, and request type of the response data, determines whether the network request was successful based on the response status code, and determines the corresponding target application layer based on the request address when the request is successful. It then performs format conversion on the response result to obtain a response body that conforms to the requirements of the target application layer, and sends the response body to the service provider.

[0046] The service provider sends the response body to the business interface in the target application layer that matches the request type, so that the target application layer obtains the response body corresponding to the original network request.

[0047] Optionally, in this embodiment of the application, the response processing module is further configured to:

[0048] When the second slice plugin determines that the request has failed, it generates response failure information corresponding to the response data based on the failure reason indicated by the response status code, and sends the response failure information to the service provider.

[0049] The service provider sends the response failure information to the target execution layer.

[0050] Optionally, in this embodiment, the intermediate layer further includes a statistician; the response processing module is further configured to:

[0051] Based on the parsing results of the response data returned by each execution layer, determine the request success rate corresponding to each execution layer and the reason for request failure corresponding to request failure;

[0052] The system analyzes the reasons for request failures at each execution layer and, based on the frequency of occurrence of different reasons, identifies high-frequency and occasional reasons for request failures. It then sends the corresponding request success rate, frequency of occurrence of each reason for request failure, high-frequency and occasional reasons for request failure to the management terminal corresponding to each execution layer.

[0053] According to another aspect of this application, a storage medium is provided that stores a computer program thereon, which, when executed by a processor, implements the above-described network request method based on abstract thinking.

[0054] According to another aspect of this application, a computer device is provided, including a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, wherein the processor executes the program to implement the above-described network request method based on abstract thinking.

[0055] By employing the above technical solutions, this application provides a network request method, apparatus, storage medium, and computer device based on abstract thinking. Through a service provider and service builder in the middle layer, it achieves unified network request processing across platforms and applications. Specific steps include: defining an application layer interface and inheriting the abstract base class interface of the middle layer to generate a business interface; the service provider receiving the original network request from the application layer and assembling it into a request object; and the service builder determining the target execution layer based on the request parameters, packaging the request object, generating a network request conforming to the target execution layer's interface specification, and sending it. This method, through unified interface specifications and middle layer encapsulation, reduces development and maintenance costs, improves system scalability and maintainability, enhances development efficiency and code quality, and strengthens system security and performance.

[0056] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0057] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0058] Figure 1 A flowchart illustrating a network request method based on abstract thinking provided in an embodiment of this application is shown.

[0059] Figure 2 A flowchart illustrating another network request method based on abstract thinking provided in an embodiment of this application is shown.

[0060] Figure 3 This illustration shows a schematic diagram of a network request device based on abstract thinking, provided in an embodiment of this application. Detailed Implementation

[0061] The present application will be described in detail below with reference to the accompanying drawings and embodiments. It should be noted that, unless otherwise specified, the embodiments and features described in the embodiments of the present application can be combined with each other.

[0062] This embodiment provides a network request method based on abstract thinking, applied to a middleware layer, which includes a service provider and a service builder, such as... Figure 1 As shown, the method includes:

[0063] Step 101: Define the application layer interface of the application layer based on the interface declaration specification of the intermediate layer, and obtain the business interface of the application layer by inheriting the abstract base class interface of the intermediate layer.

[0064] This application proposes a network request method based on abstract thinking, applied to a middleware layer, such as @jvs / api. This middleware layer is a system deployed between the application layer and the execution layer, built based on abstract thinking to summarize the information interaction methods between the two, and implements unified network request processing. This middleware layer includes service providers and service builders. This approach enables unified network request processing across platforms and applications, reducing development and maintenance costs and improving system scalability and maintainability. First, based on the middleware layer's interface declaration specification, application layer interfaces are defined. These interfaces cover all possible network request operations, such as GET, POST, PUT, and DELETE. Application layer interfaces need to inherit from the middleware layer's abstract base class interface. The abstract base class interface defines the basic methods and attributes of network requests, ensuring that all application layer interfaces have consistent behavior and structure. By inheriting from the abstract base class interface, the application layer can define specific business interfaces, which can be extended and customized according to specific business needs. For example, in fintech applications, we might define "payment request interface," "account balance query interface," etc., all of which inherit from the middleware layer's abstract base class interface. By using the abstract base class interface of the middle layer, unified network request processing can be achieved across platforms and applications, reducing differences between different platforms and applications and lowering development and maintenance costs. Furthermore, the encapsulation and processing logic of the middle layer can be reused, avoiding the need to repeatedly write the same network request code across different platforms and applications.

[0065] Step 102: The service provider receives the original network request sent by the application layer through any of the business interfaces, wherein the original network request includes a business interface instance and request parameters.

[0066] In this embodiment, the service provider is a middleware component capable of receiving raw network requests from the application layer. These raw network requests are sent through a business interface and include a business interface instance and request parameters. The business interface instance refers to an interface object that specifically implements the business logic, while the request parameters contain the specific data of the request, such as the request URL, request method, and request body.

[0067] Step 103: The service provider assembles the business interface instance and the request parameters to obtain a request object.

[0068] In this embodiment, the service provider assembles the received business interface instance and request parameters to generate a request object. The request object is a data structure that encapsulates all request information for easy subsequent processing. After assembly, the generated request object contains all necessary request information, such as the request URL, request method, request headers, and request body.

[0069] Step 104: The service builder determines the target execution layer based on the server address in the request parameters, packages the request object to obtain a network request that matches the interface specification of the target execution layer, and sends it to the target execution layer for network request processing.

[0070] In this embodiment, the service builder is another intermediate layer component that converts request objects into network requests that match the interface specification of the target execution layer. The target execution layer can be different platforms (such as H5, mini-programs, Android, iOS) or different backend services. The service builder wraps the request object to ensure it conforms to the interface specification of the target execution layer, including setting request headers, request methods, and request bodies. Finally, the service builder sends the wrapped network request to the target execution layer, which then performs the actual network request processing. This intermediate layer design provides high system flexibility. Because the application layer is decoupled from the specific network framework, the network request framework can be easily upgraded or switched without modifying the application layer code. Developers only need to focus on business logic, without needing to worry about the underlying network request implementation, thus improving development efficiency. Through this solution, applications in the fintech field can achieve more efficient and reliable network request processing, reduce development and maintenance costs, and improve system scalability and maintainability.

[0071] By applying the technical solution of this embodiment, unified network request processing across platforms and applications is achieved through the service provider and service builder of the intermediate layer. Specific steps include: defining the application layer interface and inheriting the abstract base class interface of the intermediate layer to generate a business interface; the service provider receiving the original network request from the application layer and assembling it into a request object; and the service builder determining the target execution layer based on the request parameters, packaging the request object, generating a network request conforming to the target execution layer's interface specification, and sending it. This method, through unified interface specifications and encapsulation in the intermediate layer, reduces development and maintenance costs, improves system scalability and maintainability, enhances development efficiency and code quality, and strengthens system security and performance.

[0072] Furthermore, as a refinement and extension of the specific implementation of the above embodiments, and to fully illustrate the specific implementation process of this embodiment, another network request method based on abstract thinking is provided, applied to the middle layer. The middle layer includes a service provider, a service builder, a first slice plugin, and a second slice plugin, such as... Figure 2 As shown, the method includes:

[0073] Step 201: Define the application layer interface of the application layer based on the interface declaration specification of the intermediate layer, and obtain the business interface of the application layer by inheriting the abstract base class interface of the intermediate layer.

[0074] In this embodiment, the interface declaration specification middleware defines a set of standards to guide the application layer in declaring its interfaces. These specifications ensure seamless integration between the application layer interfaces and the middleware. The interfaces defined by the application layer based on business requirements are used to send network requests to the middleware. The middleware provides a set of basic interfaces containing the fundamental methods and attributes required to handle network requests. The application layer interfaces inherit from the abstract base class interface of the middleware, thereby acquiring the ability to handle network requests and specifying the business logic. Depending on the type of request, the abstract base class interface specifically includes upload interfaces, download interfaces, and regular request interfaces.

[0075] Step 202: The service provider receives the original network request sent by the application layer through any of the business interfaces, wherein the original network request includes a business interface instance and request parameters; the service interface instance and the request parameters are assembled to obtain a request object.

[0076] In this embodiment, the original network request is sent by the application layer through a business interface, and includes a business interface instance and request parameters. The service provider combines the business interface instance and request parameters into a request object, which contains all the information required to execute the network request.

[0077] Step 203: The first slice plugin takes the request object as a request instance, obtains the public parameter information corresponding to the request instance, encapsulates the public parameter information into the request instance to obtain a new request instance, wherein the public parameter information includes a user login status token; and passes the new request instance to the service builder.

[0078] In this embodiment, the first slice plugin is an extension mechanism of the middleware layer, allowing developers to preprocess or post-process requests without modifying the core code of the middleware layer. Common parameter information refers to public parameters, such as user login state tokens. These parameters are required for all requests but may vary from request to request. The first slice plugin encapsulates the common parameter information into a request object, generating a new request instance. This ensures that each request contains the necessary authentication and authorization information, improving security.

[0079] Step 204: The service builder determines the target execution layer based on the server address in the new request instance, packages the new request instance to obtain a network request that matches the interface specification of the target execution layer, and sends it to the target execution layer for network request processing.

[0080] In this embodiment, the service builder is responsible for converting new request instances into network requests that match the interface specifications of the target execution layer. The target execution layer can be different platforms (such as H5, mini-programs, Android, and iOS) or different backend services. The service builder packages the new request instance to ensure it conforms to the interface specifications of the target execution layer, which may include setting request headers, request methods, and request bodies. Finally, the service builder sends the packaged network request to the target execution layer, which then performs the actual network request processing.

[0081] Optionally, in this embodiment, the service builder in step 204 determines the target execution layer based on the server address in the new request instance and packages the new request instance to obtain a network request that matches the interface specification of the target execution layer. This includes: the service builder injects the dependency information required by the target execution layer into the new request instance, and packages the request address, response data type, request method, request type, and request header in the request instance after injecting the dependency information to obtain a network request that matches the interface specification of the target execution layer.

[0082] In the above embodiments, the service builder first parses the server address in the new request instance to determine the target execution layer. The target execution layer can be different platforms (such as H5, mini-programs, Android, iOS) or different backend services. Based on the parsing results, the corresponding target execution layer is selected, and each execution layer has different interface specifications and requirements. The service builder identifies the dependency information required by the target execution layer, which may include authentication information, environment configuration, specific request parameters, etc. This dependency information is injected into the new request instance to ensure that the request instance contains all the necessary information so that the target execution layer can correctly process the request. The service builder adjusts the request address according to the requirements of the target execution layer, such as adding or modifying paths, query parameters, etc. The expected response data type is specified, such as JSON, XML, etc., which helps the target execution layer to correctly parse the response data. The request method (HTTP method) is set, such as GET, POST, PUT, DELETE, etc. The request type is specified, such as synchronous request or asynchronous request. Request headers are set, including but not limited to Content-Type, Authorization, etc. Request headers may contain important information such as authentication information and content encoding. After the above processing, the service builder generates a network request that perfectly matches the target execution layer's interface specification and sends the generated network request to the target execution layer for actual network request processing. In a wrapped request example: Request Address: Adjust the request address according to the requirements of the target execution layer. For example, if the target execution layer needs to include a version number in the path, the service builder will adjust the request address from / api / user to / v1 / api / user. Response Data Type: Specify the expected response data type. For example, if the target execution layer returns JSON data, the service builder will set Accept: application / json in the request header. Request Method: Set the request method. For example, if a POST request is required, the service builder will set the request method to POST. Request Type: Specify the type of request. For example, if an asynchronous request is required, the service builder will set the corresponding flag. Request Headers: Set the request headers, including but not limited to: Content-Type: Specify the content type of the request body, such as application / json. Authorization: Contain authentication information, such as Bearer. <token>User-Agent: Identifies client information. X-Custom-Header: A custom header field used to convey specific information. After the above processing, the service builder generates a network request that fully matches the target execution layer interface specification. This request contains all necessary information, such as the request address, request method, request headers, and request body. This embodiment of the application, through the processing of the service builder, can easily support multiple platforms and backend services, improving system compatibility and flexibility. The service builder can dynamically adjust the request according to the requirements of the target execution layer, ensuring that the request conforms to the target execution layer's interface specification. Furthermore, by injecting necessary dependency information, such as authentication information, the security of the request can be ensured, preventing unauthorized access.

[0083] Step 205: The service provider receives the response data returned by the target execution layer and passes the response data to the second slice plugin.

[0084] In this embodiment, the service provider receives response data returned by the target execution layer, including the response status code, response result, request address, request type, and other information. The received response data is then further passed to the second slice plugin for further processing.

[0085] Step 206: The second slice plugin parses the response data to determine the response status code, response result, request address, and request type of the response data, and determines whether the network request was successful based on the response status code.

[0086] In this embodiment, the second slice plugin parses the response data, extracting key information such as the response status code, response result, request address, and request type. The success of the network request is determined based on the response status code. This response status code is not a standard HTTP status code, but rather a custom status code defined by the middleware layer. It is used to determine whether the network request succeeded or failed based on the parsing results of the response data, and what information was missing that led to the failure. For example, a successful request (no missing content) corresponds to a 200 response status code; a missing request address corresponds to a 201 response status code; and a missing request address and response result correspond to a 202 response status code, and so on.

[0087] Step 207: When the second slice plugin determines that the request is successful, it determines the corresponding target application layer based on the request address, performs format conversion on the response result to obtain a response body that conforms to the requirements of the target application layer, and sends the response body to the service provider; the service provider sends the response body to the business interface in the target application layer that matches the request type, so that the target application layer obtains the response body corresponding to the original network request.

[0088] In this embodiment, if the request is successful, the second slicing plugin determines the corresponding target application layer based on the request address. It then further converts the response result to obtain a response body that conforms to the target application layer's requirements. For example, if the target application layer expects a JSON format response, the second slicing plugin will convert the response result to JSON format. The converted response body is then sent to the service provider. The service provider sends the response body to the business interface in the target application layer that matches the request type, enabling the target application layer to obtain the response body corresponding to the original network request. For example, the response body corresponding to the original network request for uploading information is sent to the application layer's upload business interface.

[0089] Step 208: When the second slice plugin determines that the request has failed, it generates response failure information corresponding to the response data based on the failure reason indicated by the response status code, and sends the response failure information to the service provider; the service provider sends the response failure information to the target execution layer.

[0090] In this embodiment, if the request fails, the second slice plugin generates response failure information corresponding to the response data based on the failure reason indicated by the response status code. The failure information may include error codes, error messages, and other information pre-agreed with the target execution layer that indicates the cause of the response error. The generated response failure information is sent to the service provider, which then sends it to the target execution layer so that the target execution layer can further process or record the error information. Furthermore, it should be noted that after receiving the response result, the service provider in this embodiment sequentially calls the parsing plugin, judgment plugin, and format conversion plugin in the second slice plugin to process the response result, and passes the processing result of each plugin to the next plugin. If a plugin throws an error, the service provider will interrupt the task and forward the error to the upper-layer caller, such as the previous plugin, allowing the upper-layer caller to be aware of the error that occurred during the request processing and take corresponding error handling measures, such as logging, displaying error messages, or performing error recovery. This embodiment centrally processes the response data through the second slice plugin, converting the response result into the format expected by the target application layer, ensuring the usability of the response data. The separation of service providers and second-slice plugins makes the system more modular, and the second-slice plugins can flexibly respond to different target application layers and request types.

[0091] Optionally, in this embodiment, the intermediate layer further includes a statistician; the method further includes: determining the request success rate and request failure reason corresponding to each execution layer based on the parsing results of the response data returned by each execution layer; statistically analyzing the request failure reasons of each execution layer, and determining high-frequency request failure reasons and occasional request failure reasons based on the frequency of occurrence of different request failure reasons, and sending the corresponding request success rate, frequency of occurrence of each request failure reason, high-frequency request failure reasons and occasional request failure reasons to the management terminal corresponding to each execution layer.

[0092] In this embodiment, the intermediate layer also includes a statistical analyzer. The statistical analyzer collects and analyzes the response data returned by each execution layer to determine the success rate and reasons for request failures at each execution layer, and further analyzes the frequency of occurrence of request failure reasons, thereby helping to manage and optimize network requests. Through the statistical analyzer, the success rate and reasons for network request failures can be monitored in real time, providing data support for system optimization. The statistical analyzer receives the parsing results of the response data returned by each execution layer. The parsing results include information such as the response status code, response result, request address, and request type. Based on the response status code, it determines whether the request was successful and records the success or failure status of each request. For failed requests, the statistical analyzer determines the specific reason for the request failure based on the response status code and response result. Furthermore, recording the reasons for each request failure can form a list of failure reasons. The statistical analyzer calculates the frequency of occurrence of each request failure reason based on the failure reason list. Based on the frequency of occurrence, the statistical analyzer classifies request failure reasons into high-frequency request failure reasons and occasional request failure reasons according to preset high-frequency and low-frequency thresholds. High-frequency request failure reasons refer to failure reasons that occur frequently (above the high-frequency threshold), while occasional request failure reasons refer to failure reasons that occur infrequently (below the low-frequency threshold). The generated statistical reports are sent to the management terminals corresponding to each execution layer, enabling operations and maintenance personnel to improve the applications at that layer. This embodiment of the application uses a statistical analyzer to monitor the request success rate and failure reasons of each execution layer in real time. The data provided by the statistical analyzer helps operations and maintenance personnel optimize the system and troubleshoot problems, improving system stability and performance.

[0093] By applying the technical solution of this embodiment, and through deep decoupling of the application layer and execution layer, isolating application layer interface calls and underlying network request implementations, it is possible to freely switch between different versions and products of the network request framework. Through the abstract design of the middle layer and the unified design concept, the interface definition and calls are the same regardless of the platform or application, eliminating platform and application differences, improving program scalability, maintainability, and stability, supporting AOP programming, and providing built-in plugins and custom plugins to implement business logic in the network request process.

[0094] Furthermore, as Figure 1 In its specific implementation, this application provides a network request device based on abstract thinking, applied to an intermediate layer. The intermediate layer includes service providers and service builders, such as... Figure 3 As shown, the device includes:

[0095] The application layer definition module is used to define the application layer interface of the application layer based on the interface declaration specification of the middle layer, and to obtain the business interface of the application layer by inheriting the abstract base class interface of the middle layer.

[0096] The request receiving module is used by the service provider to receive the original network request sent by the application layer through any of the business interfaces in the business interfaces, wherein the original network request includes a business interface instance and request parameters;

[0097] The request processing module is used by the service provider to assemble the business interface instance and the request parameters to obtain a request object; the service builder determines the target execution layer based on the server address in the request parameters, and packages the request object to obtain a network request that matches the interface specification of the target execution layer.

[0098] The request sending module is used to send requests to the target execution layer for network request processing.

[0099] Optionally, in this embodiment of the application, the intermediate layer further includes a first slice plugin; the request processing module is further configured to:

[0100] After the service provider assembles the business interface instance and the request parameters to obtain a request object, the first slice plugin takes the request object as a request instance, obtains the public parameter information corresponding to the request instance, and encapsulates the public parameter information into the request instance to obtain a new request instance. The public parameter information includes a user login status token.

[0101] The first slice plugin passes the new request instance to the service builder;

[0102] The service builder determines the target execution layer based on the server address in the new request instance, and packages the new request instance to obtain a network request that matches the interface specification of the target execution layer.

[0103] Optionally, in this embodiment of the application, the request processing module is further configured to:

[0104] The service builder injects the dependency information required by the target execution layer into the new request instance, and packages the request address, response data type, request method, request type and request header in the request instance after the dependency information is injected, so as to obtain a network request that matches the interface specification of the target execution layer.

[0105] Optionally, in this embodiment, the apparatus further includes a response processing module, configured to:

[0106] The service provider receives the response data returned by the target execution layer, processes the response data into a response body, and sends the response body to the business interface.

[0107] Optionally, in this embodiment, the intermediate layer further includes a second slice plugin; the response processing module is further configured to:

[0108] The service provider transmits the response data to the second slice plugin;

[0109] The second slice plugin parses the response data, determines the response status code, response result, request address, and request type of the response data, determines whether the network request was successful based on the response status code, and determines the corresponding target application layer based on the request address when the request is successful. It then performs format conversion on the response result to obtain a response body that conforms to the requirements of the target application layer, and sends the response body to the service provider.

[0110] The service provider sends the response body to the business interface in the target application layer that matches the request type, so that the target application layer obtains the response body corresponding to the original network request.

[0111] Optionally, in this embodiment of the application, the response processing module is further configured to:

[0112] When the second slice plugin determines that the request has failed, it generates response failure information corresponding to the response data based on the failure reason indicated by the response status code, and sends the response failure information to the service provider.

[0113] The service provider sends the response failure information to the target execution layer.

[0114] Optionally, in this embodiment, the intermediate layer further includes a statistician; the response processing module is further configured to:

[0115] Based on the parsing results of the response data returned by each execution layer, determine the request success rate corresponding to each execution layer and the reason for request failure corresponding to request failure;

[0116] The system analyzes the reasons for request failures at each execution layer and, based on the frequency of occurrence of different reasons, identifies high-frequency and occasional reasons for request failures. It then sends the corresponding request success rate, frequency of occurrence of each reason for request failure, high-frequency and occasional reasons for request failure to the management terminal corresponding to each execution layer.

[0117] It should be noted that other corresponding descriptions of the functional units involved in the network request device based on abstract thinking provided in this application embodiment can be found by referring to... Figures 1 to 2 The corresponding descriptions in the method will not be repeated here.

[0118] This application also provides a computer device, specifically a personal computer, server, network device, etc. The computer device includes a bus, processor, memory, and communication interface, and may also include input / output interfaces and a display device. The processor of the computer device provides computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The database of the computer device stores location information. The network interface of the computer device is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements the steps in the various method embodiments.

[0119] Those skilled in the art will understand that the structure of the computer device described above is only a partial structure related to the solution of this application, and does not constitute a limitation on the computer device to which the solution of this application is applied. A specific computer device may include more or fewer components, or combine certain components, or have different component arrangements.

[0120] In one embodiment, a computer-readable storage medium is provided, which may be non-volatile or volatile, having stored thereon a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0121] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0122] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties.

[0123] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, graphics processors, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0124] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0125] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.< / token>

Claims

1. A network request method based on abstract thinking, characterized in that, Applied to a middleware tier, which includes service providers and service builders, the method includes: The application layer interface is defined based on the interface declaration specification of the intermediate layer, and the application layer interface is obtained by inheriting the abstract base class interface of the intermediate layer; wherein, the intermediate layer also includes a first slice plugin; The service provider receives a raw network request sent by the application layer through any of the business interfaces, wherein the raw network request includes a business interface instance and request parameters; The service provider assembles the business interface instance and the request parameters to obtain a request object; The first slice plugin takes the request object as a request instance, obtains the public parameter information corresponding to the request instance, and encapsulates the public parameter information into the request instance to obtain a new request instance, wherein the public parameter information includes a user login status token; and the first slice plugin passes the new request instance to the service builder; The service builder determines the target execution layer based on the server address in the new request instance, packages the new request instance to obtain a network request that matches the interface specification of the target execution layer, and sends it to the target execution layer for network request processing.

2. The method according to claim 1, characterized in that, The process of wrapping the new request instance to obtain a network request that matches the interface specification of the target execution layer includes: The service builder injects the dependency information required by the target execution layer into the new request instance, and packages the request address, response data type, request method, request type and request header in the request instance after the dependency information is injected, so as to obtain a network request that matches the interface specification of the target execution layer.

3. The method according to any one of claims 1 to 2, characterized in that, After the request is sent to the target execution layer for network request processing, the method further includes: The service provider receives the response data returned by the target execution layer, processes the response data into a response body, and sends the response body to the business interface.

4. The method according to claim 3, characterized in that, The intermediate layer also includes a second slice plugin; the step of processing the response data into a response body and sending the response body to the business interface includes: The service provider transmits the response data to the second slice plugin; The second slice plugin parses the response data, determines the response status code, response result, request address, and request type of the response data, determines whether the network request was successful based on the response status code, and determines the corresponding target application layer based on the request address when the request is successful. It then performs format conversion on the response result to obtain a response body that conforms to the requirements of the target application layer, and sends the response body to the service provider. The service provider sends the response body to the business interface in the target application layer that matches the request type, so that the target application layer obtains the response body corresponding to the original network request.

5. The method according to claim 4, characterized in that, After determining whether the network request was successful based on the response status code, the method further includes: When the second slice plugin determines that the request has failed, it generates response failure information corresponding to the response data based on the failure reason indicated by the response status code, and sends the response failure information to the service provider. The service provider sends the response failure information to the target execution layer.

6. The method according to claim 4, characterized in that, The intermediate layer also includes a statistical analyzer; the method further includes: Based on the parsing results of the response data returned by each execution layer, determine the request success rate corresponding to each execution layer and the reason for request failure corresponding to request failure; The system analyzes the reasons for request failures at each execution layer and, based on the frequency of occurrence of different reasons, identifies high-frequency and occasional reasons for request failures. It then sends the corresponding request success rate, frequency of occurrence of each reason for request failure, high-frequency and occasional reasons for request failure to the management terminal corresponding to each execution layer.

7. A network request device based on abstract thinking, characterized in that, Applied to a middleware tier, the middleware tier including a service provider and a service builder, the apparatus includes: The application layer definition module is used to define the application layer interface of the application layer based on the interface declaration specification of the middle layer, and to obtain the business interface of the application layer by inheriting the abstract base class interface of the middle layer; wherein, the middle layer also includes a first slice plugin. The request receiving module is used by the service provider to receive the original network request sent by the application layer through any of the business interfaces in the business interfaces, wherein the original network request includes a business interface instance and request parameters; The request processing module is used by the service provider to assemble the business interface instance and the request parameters to obtain a request object; the first slice plugin takes the request object as a request instance, obtains the public parameter information corresponding to the request instance, and encapsulates the public parameter information into the request instance to obtain a new request instance, wherein the public parameter information includes a user login state token; and the first slice plugin passes the new request instance to the service builder; the service builder determines the target execution layer based on the server address in the new request instance, and packages the new request instance to obtain a network request that matches the interface specification of the target execution layer; The request sending module is used to send requests to the target execution layer for network request processing.

8. A storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 6.

9. A computer device, comprising a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method of any one of claims 1 to 6.

Images