Network request method and device based on abstract thinking, storage medium and equipment
By introducing service providers and service builders into the middle layer of the financial technology field, unified network request processing across platforms and across applications is solved, and the problems of high development costs and long project delivery cycles caused by network interface differences in the existing technology are solved, and the scalability and maintainability of the system are improved.
Patent Information
- Application Number
- CN202411758975.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-12-02
- Publication Date
- 2025-03-28
- Estimated Expiration
- 2044-12-02
AI Technical Summary
When utilizing the existing open source network framework, the financial technology field faces great differences in the implementation and calling methods of cross-platform and cross-application network interfaces between the same platform and cross-applications, resulting in high development costs, long project delivery cycles, and it is difficult to achieve flexible upgrades or switches of the framework.
By introducing service providers and service builders in the intermediate layer, a unified application layer interface is defined, and the target execution layer is determined based on the request parameters through the service builder, and network request packaging and sending of interface specification matching is realized, and unified network request processing across platforms and across applications is realized.
It reduces development and maintenance costs, improves the scalability and maintainability of the system, enhances development efficiency and code quality, and improves the security and performance of the system.
Smart Images

Figure CN119728774A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the fields of data processing and financial technology, and in particular to a network request method, device, storage medium and computer equipment based on abstract thinking. Background Art
[0002] In the field of financial technology, most of the currently 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 mini-program native request interface). The implementation mechanism of these frameworks is relatively complex and provides many APIs and configuration options. However, there are significant differences in the implementation and calling methods of network interfaces between different terminals (such as H5, mini-programs, native apps) or platforms. Therefore, many financial technology projects have to customize the network layer for each platform.
[0003] Fintech applications are highly dependent on the interfaces of third-party network frameworks to implement network requests. Since there may be implementation differences between different frameworks or different versions of the same framework, this greatly hinders the flexibility of the application layer when upgrading the framework or switching to other network request products in the future. This dependency and inconsistency increases the difficulty of technical iteration and optimization of Fintech systems in the future. For example, in the field of Fintech, there is an increasing demand for cross-platform (such as H5, mini-programs, APPs) and cross-platform development (such as different financial projects A and B). However, due to the inconsistency of network framework interfaces between platforms and applications, developers need to spend extra time and energy to adapt to and learn different network request implementation methods. This not only increases development costs, but also extends the project delivery cycle.
[0004] The FinTech sector faces many challenges and problems when using existing open source network frameworks. To solve these problems, it is necessary to explore a more unified, flexible, and easy-to-maintain network request solution. Summary of the invention
[0005] In view of this, the embodiments of the present application provide a network request method, apparatus, storage medium and computer equipment 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 the present application, a network request method based on abstract thinking is provided, which is applied to an intermediate layer, wherein the intermediate layer includes a service provider and a service builder, and the method includes:
[0007] Defining the application layer interface of the application layer based on the interface declaration specification of the middle layer, and inheriting the abstract base class interface of the middle layer to obtain the business interface of the application layer;
[0008] The service provider receives an original network request sent by the application layer through any of the service interfaces, wherein the original network request includes a service 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 according to the server address in the request parameter, 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] In the embodiment of the present application, optionally, the middle layer further includes a first slice plug-in; after the service provider assembles the business interface instance and the request parameter to obtain the request object, the method further includes:
[0012] The first slice plug-in uses the request object as a request instance, obtains 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;
[0013] The first slice plug-in passes the new request instance to the service builder;
[0014] Accordingly, the service builder determines the target execution layer according to the server address in the request parameter, 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 according to the server address in the new request instance, and performs packaging processing on the new request instance to obtain a network request that matches the interface specification of the target execution layer.
[0016] In the embodiment of the present application, optionally, the packaging process of 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 to obtain a network request that matches the interface specification of the target execution layer.
[0018] In the embodiment of the present application, optionally, after the sending 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] In the embodiment of the present application, optionally, the middle layer further includes a second slice plug-in; processing the response data into a response body, and sending the response body to the service interface includes:
[0021] The service provider passes the response data to the second slice plug-in;
[0022] The second slice plug-in 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 is successful based on the response status code, and determines the corresponding target application layer based on the request address when the request is successful, converts the format of the response result to obtain a response body that complies with 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] In the embodiment of the present application, optionally, after determining whether the network request is successful based on the response status code, the method further includes:
[0025] When determining that the request fails, the second slice plug-in generates response failure information corresponding to the response data based on the failure cause 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] In the embodiment of the present application, optionally, the intermediate layer further includes a counter; and the method further includes:
[0028] According to the analysis results of the response data returned by each execution layer, the request success rate corresponding to each execution layer and the request failure reason corresponding to the request failure are determined;
[0029] The request failure reasons of each execution layer are counted, and based on the frequency of occurrence of different request failure reasons, the high-frequency request failure reasons and the occasional request failure reasons are determined, and the corresponding request success rate, the frequency of occurrence of each request failure reason, the high-frequency request failure reasons and the occasional request failure reasons are sent to the management terminal corresponding to each execution layer.
[0030] According to another aspect of the present application, a network request device based on abstract thinking is provided, which is applied to an intermediate layer, wherein the intermediate layer includes a service provider and a service builder, and the device includes:
[0031] An application layer definition module, used to define an application layer interface of the application layer based on the interface declaration specification of the middle layer, and inherit the abstract base class interface of the middle layer from the application layer interface to obtain the business interface of the application layer;
[0032] A request receiving module, configured for the service provider to receive an original network request sent by the application layer through any of the service interfaces, wherein the original network request includes a service interface instance and request parameters;
[0033] A request processing module, used for 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 according to 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 the request to the target execution layer for network request processing.
[0035] In the embodiment of the present application, optionally, the intermediate layer further includes a first slice plug-in; and the request processing module is further used to:
[0036] After the service provider assembles the business interface instance and the request parameters to obtain a request object, the first slice plug-in uses the request object as a request instance, obtains 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;
[0037] The first slice plug-in passes the new request instance to the service builder;
[0038] The service builder determines the target execution layer according to the server address in the new request instance, and performs packaging processing on the new request instance to obtain a network request that matches the interface specification of the target execution layer.
[0039] In the embodiment of the present application, optionally, the request processing module is further used 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 to obtain a network request that matches the interface specification of the target execution layer.
[0041] In the embodiment of the present application, optionally, the device 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] In the embodiment of the present application, optionally, the intermediate layer further includes a second slice plug-in; and the response processing module is further used to:
[0044] The service provider passes the response data to the second slice plug-in;
[0045] The second slice plug-in 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 is successful based on the response status code, and determines the corresponding target application layer based on the request address when the request is successful, converts the format of the response result to obtain a response body that complies with 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] In the embodiment of the present application, optionally, the response processing module is further used to:
[0048] When determining that the request fails, the second slice plug-in generates response failure information corresponding to the response data based on the failure cause 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] In the embodiment of the present application, optionally, the intermediate layer further includes a counter; and the response processing module is further used to:
[0051] According to the analysis results of the response data returned by each execution layer, the request success rate corresponding to each execution layer and the request failure reason corresponding to the request failure are determined;
[0052] The request failure reasons of each execution layer are counted, and based on the frequency of occurrence of different request failure reasons, the high-frequency request failure reasons and the occasional request failure reasons are determined, and the corresponding request success rate, the frequency of occurrence of each request failure reason, the high-frequency request failure reasons and the occasional request failure reasons are sent to the management terminal corresponding to each execution layer.
[0053] According to another aspect of the present application, a storage medium is provided, on which a computer program is stored, and when the program is executed by a processor, the above-mentioned network request method based on abstract thinking is implemented.
[0054] According to another aspect of the present 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 implements the above-mentioned network request method based on abstract thinking when executing the program.
[0055] By means of the above technical scheme, the embodiment of the present application provides a network request method, device, storage medium and computer equipment based on abstract thinking, which realizes unified network request processing across platforms and applications through the service provider and service builder of the middle layer. The specific steps include: defining the application layer interface and inheriting the abstract base class interface of the middle layer to generate the business interface; the service provider receives the original network request of the application layer and assembles it into a request object; the service builder determines the target execution layer according to the request parameters, packages the request object, generates and sends a network request that complies with the interface specification of the target execution layer. This method reduces development and maintenance costs and improves the scalability and maintainability of the system through unified interface specifications and encapsulation of the middle layer, while improving development efficiency and code quality, and enhancing the security and performance of the system.
[0056] The above description is only an overview of the technical solution of the present application. In order to more clearly understand the technical means of the present application, it can be implemented in accordance with the contents of the specification. In order to make the above and other purposes, features and advantages of the present application more obvious and easy to understand, the specific implementation methods of the present application are listed below. BRIEF DESCRIPTION OF THE DRAWINGS
[0057] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:
[0058] Figure 1 A schematic diagram of a flow chart of a network request method based on abstract thinking provided in an embodiment of the present application is shown;
[0059] Figure 2 A schematic diagram of a process flow of another network request method based on abstract thinking provided in an embodiment of the present application is shown;
[0060] Figure 3 A schematic diagram of the structure of a network request device based on abstract thinking provided in an embodiment of the present application is shown. DETAILED DESCRIPTION
[0061] The present application will be described in detail below with reference to the accompanying drawings and in combination with embodiments. It should be noted that the embodiments and features in the embodiments of the present application can be combined with each other without conflict.
[0062] In this embodiment, a network request method based on abstract thinking is provided, which is applied to the middle layer, and the middle layer includes a service provider Provider and a service builder ServiceBuilder, such as Figure 1 As shown, the method includes:
[0063] Step 101: define an application layer interface of an application layer based on an interface declaration specification of an intermediate layer, and inherit the abstract base class interface of the intermediate layer from the application layer interface to obtain a business interface of the application layer.
[0064] The embodiment of the present application proposes a network request method based on abstract thinking, which is applied to the middle layer, such as @jvs / api. The middle layer is a system for implementing unified network request processing deployed between the application layer and the execution layer based on the information interaction mode between the application layer and the execution layer, and the middle layer includes a service provider and a service builder. In this way, unified network request processing across platforms and applications can be achieved, development and maintenance costs can be reduced, and the scalability and maintainability of the system can be improved. First, according to the interface declaration specification of the middle layer, the interface of the application layer is defined. These interfaces cover all possible network request operations, such as GET, POST, PUT, DELETE, etc. The application layer interface needs to inherit the abstract base class interface of the middle layer. The abstract base class interface defines the basic methods and properties of the network request to ensure that all application layer interfaces have consistent behavior and structure. By inheriting the abstract base class interface, the application layer can define specific business interfaces, which can be expanded and customized according to specific business needs. For example, in financial technology applications, we may define "payment request interface", "query account balance interface", etc., which all inherit the abstract base class interface of the middle layer. Through the abstract base class interface of the middle layer, unified network request processing can be achieved across platforms and applications, reducing the differences between different platforms and applications and reducing development and maintenance costs. In addition, the encapsulation and processing logic of the middle layer can be reused, avoiding the need to repeatedly write the same network request code in different platforms and applications.
[0065] Step 102: The service provider receives an 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 the embodiment of the present application, the service provider is a middle-layer component that can receive the original network request from the application layer. The original network request is sent through the business interface and includes a business interface instance and request parameters. The business interface instance refers to the interface object that specifically implements the business logic, and the request parameters include the specific data of the request, such as the request URL, request method, request body, etc.
[0067] Step 103: The service provider assembles the business interface instance and the request parameters to obtain a request object.
[0068] In the embodiment of the present application, the service provider assembles the received business interface instance and request parameters to generate a request object, which is a data structure that encapsulates all request information for subsequent processing. After the assembly is completed, the generated request object contains all necessary request information, such as request URL, request method, request header, request body, etc.
[0069] Step 104: The service builder determines the target execution layer according to the server address in the request parameter, 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 the embodiment of the present application, the service builder is another middle layer component that can convert the request object into a network request that matches the interface specification of the target execution layer. The target execution layer can be different platforms (such as H5, applet, Android, iOS) or different back-end services. The service builder packages the request object to ensure that it complies with the interface specification of the target execution layer, including setting the request header, request method, request body, etc. Finally, the service builder sends the packaged network request to the target execution layer, and the target execution layer performs the actual network request processing. The design of the middle layer makes the system highly flexible. Since 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 and do not need to care about the specific implementation of the underlying network request, which improves development efficiency. Through the above scheme, applications in the field of financial technology can achieve more efficient and reliable network request processing, reduce development and maintenance costs, and improve the scalability and maintainability of the system.
[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 middle layer. The specific steps include: defining the application layer interface and inheriting the abstract base class interface of the middle layer to generate the business interface; the service provider receives the original network request of the application layer and assembles it into a request object; the service builder determines the target execution layer according to the request parameters, packages the request object, generates and sends a network request that complies with the interface specification of the target execution layer. This method reduces development and maintenance costs and improves the scalability and maintainability of the system through unified interface specifications and encapsulation of the middle layer, while improving development efficiency and code quality, and enhancing the security and performance of the system.
[0072] Further, as a refinement and extension of the specific implementation of the above embodiment, in order to fully illustrate the specific implementation process of this embodiment, another network request method based on abstract thinking is provided, which is applied to the middle layer, and the middle layer includes a service provider, a service builder, a first slice plug-in and a second slice plug-in, such as Figure 2 As shown, the method includes:
[0073] Step 201: define an application layer interface of the application layer based on the interface declaration specification of the middle layer, and inherit the abstract base class interface of the middle layer to obtain the business interface of the application layer.
[0074] In the embodiments of the present application, the interface declaration specification defines a set of standards in the middle layer to guide the application layer on how to declare its interface. These specifications ensure that the application layer interface and the middle layer can be seamlessly connected. The interface defined by the application layer according to business needs is used to send network requests to the middle layer. The middle layer provides a set of basic interfaces, which include the basic methods and properties required to process network requests. The application layer interface inherits the abstract base class interface of the middle layer, obtains the ability to process network requests, and concretizes the business logic. Depending on the type of request, the abstract base class interface specifically includes an upload interface, a download interface, and a normal request interface.
[0075] Step 202: The service provider receives an 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; and assembles the business interface instance and the request parameters to obtain a request object.
[0076] In the embodiment of the present application, the original network request is a request sent by the application layer through the business interface, including 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 plug-in 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 an embodiment of the present application, the first slice plug-in is an extension mechanism of the middle layer, which allows developers to pre-process or post-process requests without modifying the core code of the middle layer. Public parameter information refers to public parameters, such as user login tokens, which are required for all requests but may vary from request to request. The first slice plug-in encapsulates the public parameter information into the request object and generates a new request instance. Doing so ensures that each request contains the necessary authentication and authorization information, thereby improving security.
[0079] Step 204: The service builder determines the target execution layer according to 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 the embodiment of the present application, the service builder is responsible for converting the new request instance into a network request that matches the target execution layer interface specification. The target execution layer can be different platforms (such as H5, applet, Android, iOS) or different back-end services. The service builder packages the new request instance to ensure that it complies with the interface specification of the target execution layer, which may include setting the request header, request method, request body, etc. Ultimately, the service builder sends the packaged network request to the target execution layer, which performs the actual network request processing.
[0081] In an embodiment of the present application, optionally, in step 204, 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, including: 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 to obtain a network request that matches the interface specification of the target execution layer.
[0082] In the above embodiment, the service builder first parses the server address in the new request instance to determine the target execution layer, which can be different platforms (such as H5, applet, Android, iOS) or different backend services. According to 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. These dependency information are injected into the new request instance to ensure that the request instance contains all 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, for example, including adding or modifying the path, query parameters, etc. Specifying the expected response data type, such as JSON, XML, etc., helps the target execution layer to correctly parse the response data. Set the request mode (HTTP method), such as GET, POST, PUT, DELETE, etc. Specify the request type, such as synchronous request or asynchronous request. Set the request header, including but not limited to Content-Type, Authorization, etc. The request header may contain important information such as authentication information and content encoding. After the above processing, the service builder generates a network request that fully matches the interface specification of the target execution layer, and sends the generated network request to the target execution layer, which performs the actual network request processing. In a packaging 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 data in JSON format, the service builder will set Accept: application / json in the request header. Request method: set the request method. For example, if a POST request needs to be sent, the service builder will set the request method to POST. Request type: specify the type of request. For example, if an asynchronous request needs to be sent, the service builder will set the corresponding flag. Request header: set the request header, including but not limited to: Content-Type: specify the content type of the request body, such as application / json. Authorization: contains authentication information, such as Bearer <token>. User-Agent: identifies the client information. X-Custom-Header: a custom header field used to pass specific information. After the above processing, the service builder generates a network request that fully matches the interface specification of the target execution layer. This request contains all the necessary information, such as the request address, request method, request header, request body, etc. Through the processing of the service builder, the embodiment of the present application can easily support a variety of platforms and back-end services, improve the compatibility and flexibility of the system, and the service builder can dynamically adjust the request according to the requirements of the target execution layer to ensure that the request complies with the interface specification of the target execution layer. In addition, by injecting necessary dependency information, such as authentication information, the security of the request can be ensured to prevent 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 plug-in.
[0084] In the embodiment of the present application, the service provider receives the response data returned by the target execution layer, including the response status code, response result, request address, request type, etc., and further passes the received response data to the second slice plug-in for further processing.
[0085] Step 206: The second slice plug-in parses the response data, determines the response status code, response result, request address, and request type of the response data, and determines whether the network request is successful based on the response status code.
[0086] In an embodiment of the present application, the second slice plug-in parses the response data and extracts key information such as the response status code, response result, request address, and request type. Whether the network request is successful is determined based on the response status code. The response status code here is not a status code of the HTTP type, but a custom status code of the middle layer, which is used to determine the success or failure of the network request based on the parsed result of the response data, and what kind of information is missing to determine that the network request failed. For example, if the request is successful, there is no lack of content that needs to be returned, and the corresponding response status code is 200. When the request address is missing, the corresponding response status code is 201. When the request address and response result are missing, the corresponding response status code is 202, and so on.
[0087] Step 207: When the second slice plug-in determines that the request is successful, it determines the corresponding target application layer based on the request address, converts the format of the response result to obtain a response body that complies with 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 an embodiment of the present application, if the request is successful, the second slice plug-in determines the corresponding target application layer based on the request address, and further converts the format of the response result to obtain a response body that complies with the requirements of the target application layer. For example, if the target application layer expects a response in JSON format, the second slice plug-in will convert the response result into JSON format. The converted response body is 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, so that the target application layer obtains 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 upload business interface of the application layer.
[0089] Step 208: When determining that the request has failed, the second slice plug-in generates response failure information corresponding to the response data based on the failure cause 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 the embodiment of the present application, if the request fails, the second slice plug-in 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 that are pre-agreed with the target execution layer to indicate the cause of the error in the response result. The generated response failure information is sent to the service provider, and the service provider sends the response failure information to the target execution layer so that the target execution layer can further process or record the error information. In addition, it should be noted that after receiving the response result, the service provider in the embodiment of the present application will call the parsing plug-in, the judgment plug-in, and the format conversion plug-in in the second slice plug-in in sequence to process the response result, and pass the processing result of each plug-in to the next plug-in. If a plug-in throws an error, the service provider will interrupt the task and throw the error to the upper caller, such as the previous plug-in, so that the upper caller can perceive the error that occurred during the request processing and take corresponding error handling measures, such as logging, displaying error prompt information, or performing error recovery. In the embodiment of the present application, the response data is centrally processed by the second slice plug-in, and the response result is converted into the format expected by the target application layer to ensure the availability of the response data. The separation design of the service provider and the second slice plug-in makes the system more modular, and the second slice plug-in can flexibly respond to different target application layers and request types.
[0091] In an embodiment of the present application, optionally, the middle layer also includes a counter; the method also includes: determining the request success rate corresponding to each execution layer and the request failure reason corresponding to the request failure according to the analysis results of the response data returned by each execution layer; counting the request failure reasons of each execution layer, and based on the frequency of occurrence of different request failure reasons, determining the high-frequency request failure reasons and the occasional request failure reasons, and sending the corresponding request success rate, the frequency of occurrence of each request failure reason, the high-frequency request failure reasons and the occasional request failure reasons to the management terminal corresponding to each execution layer.
[0092] In this embodiment, the middle layer also includes a counter. The function of the counter is to collect and analyze the response data returned by each execution layer to determine the request success rate and request failure reason of each execution layer, and further count the occurrence frequency of the request failure reason, so as to help manage and optimize network requests. Through the counter, the success rate and failure reason of the network request can be monitored in real time, providing data support for system optimization. The counter receives the parsing results of the response data returned by each execution layer. The parsing results include information such as response status code, response result, request address, and request type. Based on the response status code, it is determined whether the request is successful, and the success or failure of each request is recorded. For failed requests, the counter determines the specific reason for the request failure based on the response status code and the response result. Further, by recording the reason for each request failure, a failure reason list can be formed, and the counter calculates the occurrence frequency of each request failure reason based on the failure reason list. Based on the occurrence frequency, the counter divides the request failure reason into high-frequency request failure reason and occasional request failure reason according to the preset high-frequency threshold and low-frequency threshold. High-frequency request failure reasons refer to failure reasons with a high frequency (greater than the high-frequency threshold), and occasional request failure reasons refer to failure reasons with a low frequency (lower than the low-frequency threshold). The generated statistical report is sent to the management terminal corresponding to each execution layer so that the operation and maintenance personnel can improve the execution layer application. The embodiment of the present application can monitor the request success rate and request failure reasons of each execution layer in real time through the statistics device. The data support provided by the statistics device helps the operation and maintenance personnel to optimize the system and troubleshoot, thereby improving the stability and performance of the system.
[0093] By applying the technical solution of this embodiment, by deeply decoupling the application layer and the execution layer, isolating the application layer interface call and the underlying network request implementation, it is possible to switch the network request framework of different versions and different products at will; through the abstract design and unified design concept of the middle layer, no matter which platform or application, the interface definition and call are the same, which eliminates the platform and application differences, improves the program scalability, maintainability, and stability, supports AOP programming, and provides built-in plug-ins and custom plug-ins to implement business in the network request process.
[0094] Further, as Figure 1 The specific implementation of the method, the embodiment of the present application provides a network request device based on abstract thinking, which is applied to the middle layer, and the middle layer includes a service provider and a service builder, such as Figure 3 As shown, the device comprises:
[0095] An application layer definition module, used to define an application layer interface of the application layer based on the interface declaration specification of the middle layer, and inherit the abstract base class interface of the middle layer from the application layer interface to obtain the business interface of the application layer;
[0096] A request receiving module, configured for the service provider to receive an original network request sent by the application layer through any of the service interfaces, wherein the original network request includes a service interface instance and request parameters;
[0097] A request processing module, used for 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 according to 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 the request to the target execution layer for network request processing.
[0099] In the embodiment of the present application, optionally, the intermediate layer further includes a first slice plug-in; and the request processing module is further used to:
[0100] After the service provider assembles the business interface instance and the request parameters to obtain a request object, the first slice plug-in uses the request object as a request instance, obtains 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;
[0101] The first slice plug-in passes the new request instance to the service builder;
[0102] The service builder determines the target execution layer according to the server address in the new request instance, and performs packaging processing on the new request instance to obtain a network request that matches the interface specification of the target execution layer.
[0103] In the embodiment of the present application, optionally, the request processing module is further used 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 to obtain a network request that matches the interface specification of the target execution layer.
[0105] In the embodiment of the present application, optionally, the device 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] In the embodiment of the present application, optionally, the intermediate layer further includes a second slice plug-in; and the response processing module is further used to:
[0108] The service provider passes the response data to the second slice plug-in;
[0109] The second slice plug-in 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 is successful based on the response status code, and determines the corresponding target application layer based on the request address when the request is successful, converts the format of the response result to obtain a response body that complies with 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] In the embodiment of the present application, optionally, the response processing module is further used to:
[0112] When determining that the request fails, the second slice plug-in generates response failure information corresponding to the response data based on the failure cause 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] In the embodiment of the present application, optionally, the intermediate layer further includes a counter; and the response processing module is further used to:
[0115] According to the analysis results of the response data returned by each execution layer, the request success rate corresponding to each execution layer and the request failure reason corresponding to the request failure are determined;
[0116] The request failure reasons of each execution layer are counted, and based on the frequency of occurrence of different request failure reasons, the high-frequency request failure reasons and the occasional request failure reasons are determined, and the corresponding request success rate, the frequency of occurrence of each request failure reason, the high-frequency request failure reasons and the occasional request failure reasons are sent to the management terminal corresponding to each execution layer.
[0117] It should be noted that for other corresponding descriptions of the functional units involved in the network request device based on abstract thinking provided in the embodiment of the present application, reference can be made to Figure 1 to Figure 2 The corresponding description in the method will not be repeated here.
[0118] The embodiment of the present application also provides a computer device, which can be a personal computer, a server, a network device, etc. The computer device includes a bus, a processor, a memory and a communication interface, and can also include an input and output interface and a display device. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the computer device is used to store location information. The network interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, the steps in each method embodiment are implemented.
[0119] Those skilled in the art will appreciate that the structure of the above-mentioned computer device is only a partial structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components, or combine certain components, or have a different arrangement of components.
[0120] In one embodiment, a computer-readable storage medium is provided. The computer-readable storage medium may be non-volatile or volatile, and stores a computer program thereon. When the computer program is executed by a processor, the steps in the above-mentioned method embodiments are implemented.
[0121] In one embodiment, a computer program product is provided, including a computer program, which implements the steps in the above method embodiments when executed by a processor.
[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, stored data, displayed data, 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 can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to the memory, database or other medium used in the embodiments provided in the present 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), magnetoresistive 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. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in each embodiment provided in this application may include at least one of a relational database and a non-relational database. Non-relational databases may include distributed databases based on blockchains, etc., but are not limited to this. The processor involved in each embodiment provided in this application may be a general-purpose processor, a graphics processor, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, etc., but are not limited to this.
[0124] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, 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 above-described embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the present application. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the attached claims.< / token>
Claims
1. A network request method based on abstract thinking, characterized in that: Applied to an intermediate layer, the intermediate layer includes a service provider and a service builder, the method includes: Defining the application layer interface of the application layer based on the interface declaration specification of the middle layer, and inheriting the abstract base class interface of the middle layer to obtain the business interface of the application layer; The service provider receives an original network request sent by the application layer through any of the service interfaces, wherein the original network request includes a service interface instance and request parameters; The service provider assembles the business interface instance and the request parameters to obtain a request object; The service builder determines the target execution layer according to the server address in the request parameter, 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.
2. The method according to claim 1, characterized in that The middle layer also includes a first slice plug-in; the service provider assembles the business interface instance and the request parameter to obtain the request object, and the method further includes: The first slice plug-in uses the request object as a request instance, obtains 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; The first slice plug-in passes the new request instance to the service builder; Accordingly, the service builder determines the target execution layer according to the server address in the request parameter, and packages the request object to obtain a network request that matches the interface specification of the target execution layer, including: The service builder determines the target execution layer according to the server address in the new request instance, and performs packaging processing on the new request instance to obtain a network request that matches the interface specification of the target execution layer.
3. The method according to claim 2, characterized in that The packaging process of the new request instance to obtain a network request matching 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 to obtain a network request that matches the interface specification of the target execution layer.
4. The method according to any one of claims 1 to 3, characterized in that After sending the request 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.
5. The method according to claim 4, characterized in that The middle layer also includes a second slice plug-in; the processing the response data into a response body, and sending the response body to the service interface includes: The service provider passes the response data to the second slice plug-in; The second slice plug-in 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 is successful based on the response status code, and determines the corresponding target application layer based on the request address when the request is successful, converts the format of the response result to obtain a response body that complies with 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.
6. The method according to claim 5, characterized in that After determining whether the network request is successful based on the response status code, the method further includes: When determining that the request fails, the second slice plug-in generates response failure information corresponding to the response data based on the failure cause 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.
7. The method according to claim 5, characterized in that The intermediate layer also includes a counter; the method also includes: According to the analysis results of the response data returned by each execution layer, the request success rate corresponding to each execution layer and the request failure reason corresponding to the request failure are determined; The request failure reasons of each execution layer are counted, and based on the frequency of occurrence of different request failure reasons, the high-frequency request failure reasons and the occasional request failure reasons are determined, and the corresponding request success rate, the frequency of occurrence of each request failure reason, the high-frequency request failure reasons and the occasional request failure reasons are sent to the management terminal corresponding to each execution layer.
8. A network request device based on abstract thinking, characterized in that: Applied to an intermediate layer, the intermediate layer includes a service provider and a service builder, the device includes: An application layer definition module, used to define an application layer interface of the application layer based on the interface declaration specification of the middle layer, and inherit the abstract base class interface of the middle layer from the application layer interface to obtain the business interface of the application layer; A request receiving module, configured for the service provider to receive an original network request sent by the application layer through any of the service interfaces, wherein the original network request includes a service interface instance and request parameters; A request processing module, used for 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 according to 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; The request sending module is used to send the request to the target execution layer for network request processing.
9. A storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the method according to any one of claims 1 to 7 is implemented.
10. A computer device comprising a storage medium, a processor, and a computer program stored in the storage medium and executable on the processor, characterized in that: When the processor executes the computer program, the method according to any one of claims 1 to 7 is implemented.
Citation Information
Patent Citations
Mobile phone payment method based on WEB technology for realizing platform crossing
CN101841569A
Network request processing method and processing device
CN107438097A
Cross-domain-name joint debugging method and system used for voice dialogue platform
CN109639788A
Request processing method and system for application intermediate layer
CN111881394A
Interface calling method and device, storage medium and electronic equipment
CN114064158A