Network request processing method, device, equipment and program product

Abstract

The invention relates to the field of network data processing, in particular to a network request processing method and device, equipment and a program product. The method comprises the following steps: sending a network request, and obtaining a first observable object generated by the network request; the global error conversion class is inserted into the first observable object through a combination operator, a second observable object is obtained, and the global error conversion class is used for unified processing according to the type of the global error; and receiving response data of the network request, and performing conversion processing on the response data through the global error conversion class to obtain a processing result corresponding to the response data. According to the method, all errors are uniformly processed by the global error conversion class, and no matter what errors are returned by the network request, the errors can be processed by the conversion class, so that a developer does not need to nest a plurality of callbacks in the callbacks, the code development amount is reduced, only the global error conversion class needs to be updated, the maintenance cost is reduced, and the code readability is improved.

Description

Technical Field

[0001] The present application relates to the field of network data processing, and in particular to a network request processing method, device, equipment and program product. Background Art

[0002] In the process of Android application development, developers face rapid changes and diversification of functional requirements, which means that each app may have unique operating requirements and communication protocols with the server. This diversity and complexity brings a series of challenges, especially in network request processing. Network requests are often affected by factors such as network fluctuations, server errors, and data format mismatches, so each request needs to be handled with exceptions to ensure the stability of the app and user experience.

[0003] However, due to the instability of the network environment, the variability of server status, and the complexity of the protocol between the client and the server, network requests often encounter various exceptions. The traditional processing method is usually to handle exceptions through interface calls after each network request. Although this method can realize asynchronous data processing, each network request must be handled with exceptions, which has a high development time and labor cost. In addition, in order to handle complex situations, developers may need to nest multiple callbacks in the callback, which makes the code less readable and difficult to maintain. Summary of the invention

[0004] In view of this, the embodiments of the present application provide a network request processing method, apparatus, device and program product to solve the problem of high development cost and poor code readability when performing network request processing in the prior art, which is not conducive to reducing the difficulty of maintenance.

[0005] A first aspect of an embodiment of the present application provides a network request processing method, the method comprising: Send a network request and obtain a first observable object generated by the network request; Inserting a global error conversion class into the first observable object through a combination operator to obtain a second observable object, wherein the global error conversion class is used for unified processing according to the type of global errors; Receive response data of the network request, convert the response data through the global error conversion class, and obtain a processing result corresponding to the response data.

[0006] In combination with the first aspect, in a first possible implementation manner of the first aspect, receiving response data of the network request, converting the response data through the global error conversion class, and obtaining a processing result corresponding to the response data includes: Receive response data of the network request through a base class, wherein the base class includes a status code, returned data, and a prompt; The global error conversion class converts the response data according to the status code, returned data and prompt included in the base class to obtain a processing result corresponding to the response data.

[0007] In combination with the first possible implementation manner of the first aspect, in a second possible implementation manner of the first aspect, the global error conversion class converts the response data according to the status code, returned data, and prompt included in the base class to obtain a processing result corresponding to the response data, including: Determine the response type corresponding to the status code of the base class according to a predetermined correspondence between the status code and the response type; According to the response type, the response data is converted by the global error conversion class to obtain a processing result corresponding to the response data.

[0008] In combination with the second possible implementation manner of the first aspect, in a third possible implementation manner of the first aspect, according to the response type, converting the response data by the global error conversion class to obtain a processing result corresponding to the response data includes: When the response type is a normal response, transmitting the returned data included in the base class to the downstream; When the response type is an abnormal response, the status code and prompt in the base class are mapped to the globally converted error code and text description information according to a preset mapping relationship to obtain the processing result corresponding to the response data.

[0009] In combination with the second possible implementation manner of the first aspect, in a fourth possible implementation manner of the first aspect, according to the response type, converting the response data by the global error conversion class to obtain a processing result corresponding to the response data includes: When the response type is a type to be retried, determining to re-execute the second observable object according to a retry operator.

[0010] In combination with the fourth possible implementation manner of the first aspect, in a fifth possible implementation manner of the first aspect, the type to be retried includes at least one of a network abnormality type and a server failure type.

[0011] In combination with the first possible implementation manner of the first aspect, in a sixth possible implementation manner of the first aspect, the global error conversion class converts the response data according to the status code, returned data, and prompt included in the base class to obtain a processing result corresponding to the response data, including: When the global error conversion class determines that the returned data included in the base class is unexpected data, the returned data is converted into abnormal data; The error code and text description information included in the processing result of the returned data are determined according to the correspondence between the abnormal data and the error code and text description information after global conversion.

[0012] A second aspect of an embodiment of the present application provides a network request processing device, the device comprising: A first observable object generating unit, configured to send a network request and obtain a first observable object generated by the network request; an insertion unit, configured to insert a global error conversion class into the first observable object through a combination operator to obtain a second observable object, wherein the global error conversion class is used for unified processing according to the type of the global error; The conversion processing unit is used to receive the response data of the network request, convert the response data through the global error conversion class, and obtain the processing result corresponding to the response data.

[0013] A third aspect of an embodiment of the present application provides a network request processing device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, the network request processing device implements a method as described in any one of the first aspects.

[0014] A fourth aspect of the embodiments of the present application provides a computer program product, which, when executed on a computer, enables the computer to execute the method in the first aspect or its various implementations.

[0015] A fifth aspect of an embodiment of the present application provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the method described in any one of the first aspects are implemented.

[0016] The sixth aspect of the embodiment of the present application provides a chip for implementing the methods in each implementation of the first aspect. Specifically, the chip includes: a processor for calling and running a computer program from a memory, so that a device equipped with the chip executes the method in the first aspect or its implementation.

[0017] Compared with the prior art, the embodiments of the present application have the following beneficial effects: in the method of processing network requests in the embodiments of the present application, according to the first observable object generated by the network request, the global error conversion class is inserted into the first observable object through the combination operator to obtain the second observable object, and the response data of the network request is received through the second observable object. All errors are uniformly processed by the global error conversion class. No matter what error is returned by the network request, it can be processed by this conversion class, so that developers do not need to nest multiple callbacks in the callback, reducing the amount of code development. They only need to update the global error conversion class, which is conducive to reducing maintenance costs and improving code readability. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0019] Figure 1 It is a schematic diagram of an implementation scenario of a network request processing method provided in an embodiment of the present application; Figure 2 It is a schematic diagram of an implementation flow of a network request processing method provided in an embodiment of the present application; Figure 3 It is a schematic diagram of an implementation flow of a conversion processing method provided in an embodiment of the present application; Figure 4 It is a schematic diagram of an implementation flow of a network request processing method provided in an embodiment of the present application; Figure 5 is a schematic diagram of a network request processing device provided in an embodiment of the present application; Figure 6 It is a schematic diagram of a network request processing device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0020] In the following description, specific details such as specific system structures, technologies, etc. are provided for the purpose of illustration rather than limitation, so as to provide a thorough understanding of the embodiments of the present application. However, it should be clear to those skilled in the art that the present application may also be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted to prevent unnecessary details from obstructing the description of the present application.

[0021] In order to illustrate the technical solution described in this application, a specific embodiment is provided below for illustration.

[0022] In the current App development process, facing the changing functional requirements and operational requirements of App, developers need to deal with a series of challenges, especially in the data processing of network requests. The following are some specific challenges and problems, and their impact on the development process: 1. Complexity of functional requirements: Modern apps usually contain multiple functions, such as social, payment, multimedia processing, etc., which may involve complex business logic. The complexity of functional requirements leads to more diverse network requests, and each request may need to handle different data structures and error conditions.

[0023] 2. Differences in operational requirements: Different apps may have different requirements for user operations, such as login authentication, data synchronization, real-time updates, etc. The differences in these operational requirements mean that each network request requires specific processing logic, including the construction of request parameters, parsing of response data, and error handling.

[0024] 3. Different protocols agreed with the server: Each App may have different data exchange protocols with the backend server, such as RESTful API, GraphQL, etc. The difference in protocols leads to the diversity of network requests, and developers need to write specific processing code for each protocol.

[0025] 4. Complexity of exception handling: Various exceptions may occur during network requests, such as network errors, server errors, data parsing errors, etc. Each request requires targeted exception handling logic, which increases the complexity of the code and the workload of development.

[0026] In traditional Android development, network requests are usually processed through interface callbacks, such as using AsyncTask, Handler (AsyncTask and Handler are tools for handling asynchronous tasks and thread operations on the Android platform) or callback interfaces. This processing method easily leads to multi-level nesting of code, making the code difficult to read and maintain. In addition, multi-level nested callback code makes it difficult to track the execution flow of the code. Developers who are new to the project need to spend more time to understand the existing code structure, making the code less readable and making code review and testing more difficult.

[0027] Figure 1A schematic diagram of an implementation scenario of network request processing provided for an embodiment of the present application, the implementation scenario includes a client 1 and a server 2. Among them, the client 1 can send a network request to the server 2, and the server can parse the network request, execute necessary business logic, access a database or other data source, and generate response data, and send the response data to the client 1. While sending the network request, the client 1 will generate a first observable object according to the network request, insert the global error conversion class into the first observable object through the combination operator, and obtain the second observable object. For the response data of the received network request, it can be converted and processed by the global error conversion class in the second observable object to obtain the processing result corresponding to the response data. Through the unified processing of the global error conversion class of the second observable object, no matter what error the network request returns, it can be processed by this conversion class, so that the developer does not need to nest multiple callbacks in the callback, reducing the amount of code development, and only needs to update the global error conversion class, which is conducive to reducing maintenance costs and improving code readability.

[0028] Figure 2 A network request processing method is proposed for an embodiment of the present application, and the network request processing method includes: In S201, a network request is sent, and a first observable object generated by the network request is obtained.

[0029] On the APP side (i.e., the client), you can pre-define a network request interface, which describes the detailed information required for the client to communicate with the server, including one or more of the requested URL, request method, required request header or request body, etc. Create a network request service based on the pre-defined network request interface. For example, this can be achieved through network libraries such as Retrofit, Volley, or OkHttp, which are used to create network requests.

[0030] While the client sends a network request to the server, the embodiment of the present application may use a responsive programming library, including RxJava, to create an observable object, namely, a first observable object (observable1).

[0031] Among them, RxJava is an asynchronous programming framework for development applications. RxJava can be based on the extended observer design pattern and has a high degree of simplicity. RxJava can make the code call process clear and visible through chain calls. Various asynchronous operations can be organized in sequence. When processing asynchronous data streams, a series of transformations such as filtering, conversion, and merging can be performed on the sent messages through a variety of operators to meet the data processing needs in different scenarios.

[0032] It is understandable that the first observable object may be created without being limited to RxJava, and responsive programming libraries such as Kotlin Flow and ProjectReactor may also be used.

[0033] Among them, the first observable object is an observable object, whose English name is observable. The observable object observable is a data stream that can emit events and is also an observable data source. The observable object can emit a series of events, which can be data items, errors or completion signals. The observable can interact with the observer through the subscription mechanism. After the observer subscribes to the observable, it can receive the events emitted by the observable.

[0034] After sending a network request, the network request can be automatically encapsulated as the first observable object through the support of responsive programming provided by the network library. Alternatively, the first observable object can be automatically generated after monitoring the sending of the network request.

[0035] In S202, a global error conversion class is inserted into the first observable object through a combination operator to obtain a second observable object.

[0036] Among them, the global error conversion class is used to uniformly handle global errors according to their types, encapsulating various abnormal situations into a unified format so that the front end or other callers can understand and handle these errors in a consistent manner.

[0037] When processing, modifying or replacing the first observable object, the global error conversion class can be inserted into the first observable object through the compose operator to obtain the second observable object.

[0038] Among them, the global error conversion class is used to uniformly handle various errors that may occur in network requests, converting errors into a unified format, making the error handling logic more centralized and consistent. By converting errors into a unified format, the error handling of downstream logic can be simplified, duplicate error handling code can be reduced, and the maintainability and readability of the code can be improved.

[0039] You can first complete the definition of the global error conversion class, and then use the compose operator to apply the defined global error conversion class to the first observable object observable1 to obtain the second observable object observable2, that is, the first observable object observable1 with the global error conversion class inserted or applied.

[0040] In S203, response data of the network request is received, and the response data is converted and processed by the global error conversion class to obtain a processing result corresponding to the response data.

[0041] The response data of a network request may include information such as status code, returned data (Response Data) and prompt (Message). The status code is an important part of the server response, usually a numeric code used to indicate the processing result of the request. Common status codes include: 200: Success. Indicates that the network request has been successfully processed by the server.

[0042] 400: Client error. Indicates that the network request has a syntax error or the request cannot be processed.

[0043] 401: Unauthorized. Indicates that the network request requires user authentication.

[0044] 403: Forbidden. Indicates that the server understood the request but is refusing to execute it.

[0045] 404: Not Found. Indicates that the resource requested by the network does not exist on the server.

[0046] 500: Internal Server Error. Indicates that the server encountered an unexpected condition that prevented it from fulfilling the request.

[0047] The status code allows the client to quickly understand whether the request was successful and the reason for failure.

[0048] The returned data (Response Data) is the main content of the server's response, which contains the information or resources expected by the request. This data is usually encoded in JSON, XML or other formats, and can be parsed and processed by the client's application logic. For example, if the client requests to obtain user information from the server, the returned data may contain the user's name, email address, address and other information.

[0049] A message is a piece of text that the server provides to the client to describe additional information or error details of the response. Messages are usually used together with status codes to provide clients with more specific error information. For example, if the status code is 404, the message may be "The requested resource was not found" to help developers quickly locate the problem.

[0050] The embodiment of the present application can receive the response data through the base class to realize the processing of the response data, such as Figure 3 As shown, the method includes: In S301, response data of the network request is received through a base class, where the base class includes a status code, returned data, and a prompt.

[0051] The base class defines the structure followed by network request data, which usually includes at least a status code, returned data, and a prompt. The status code is used to indicate the processing result of the request, and different status codes represent different response statuses. The returned data is the specific business data returned by the server, which can be any type of data, such as user information, a list of products, etc., or a null value (the request was unsuccessful). The prompt is used to provide additional information about the response status. The prompt can explain the status code and can be an application-specific business logic error message.

[0052] In S302, the global error conversion class converts the response data according to the status code, returned data and prompt included in the base class to obtain a processing result corresponding to the response data.

[0053] The Global Error Converter class is responsible for processing the status code, returned data, and prompts in the base class, and performs the following operations based on this information: Error Identification: The global error conversion class can first check the status code to determine whether the response represents a successful operation or an error. Based on the checked status code, it can decide whether error handling logic needs to be executed.

[0054] The global error conversion class converts the response data according to the status code, returned data and prompt included in the base class, and when obtaining the processing result corresponding to the response data, the response type corresponding to the status code of the base class can be determined according to the correspondence between the status code returned by the network request and the response type. The correspondence can be determined according to the protocol between the client and the server or predefined information.

[0055] For example, based on the status code returned by the network request, the determined response type may include abnormal response types such as network error, parsing error, connection failure, host exception, I / O exception, connection timeout, certificate verification failure, unknown error, etc., or it may also include normal response types.

[0056] The global error conversion class can be used to uniformly handle different response types of different protocols and different apps, including the processing of normal responses and abnormal responses.

[0057] When the response type is an exception response, the do on error operator can be used to determine the unified error code and text description information corresponding to different error types.

[0058] For example, the correspondence between the error code determined by executing the operator when an error occurs and the text description information may include: 1101 network error, 1102 parsing error, 1103 connection failure, 1104 host exception, 1105 I / O exception, 1106 connection timeout, 1107 certificate verification failure, 500 server exception and 1100 unknown error and other abnormal response types, or also include normal response types.

[0059] If the parsed response type is a normal response, including when the data is normal, the data can be passed normally to the downstream, including the returned data included in the base class.

[0060] If the parsed response type is an abnormal response, including when the data is abnormal data, the status code and prompt in the base class can be mapped to the unified error code and text description information after global conversion according to the pre-set mapping relationship, and the processing result corresponding to the response data, that is, the converted error code and text description information, can be obtained. By subscribing to the second observable object observable2, the user can be informed of the unified text description information and error code of the current exception.

[0061] In addition, when the embodiment of the present application converts the response data, it can also determine that the response type is a type to be retried, and can re-execute the operation flow corresponding to the second observable object according to the heavy operator, such as through the retrywhen operator. That is, the completion or error notification of the second observable object is allowed to determine whether to repeat the execution of the second observable object.

[0062] The type to be retried may include at least one of a network abnormality type and a server failure type.

[0063] When an app requests data, it can usually retry if it encounters network instability, network request timeout, or interruption. If the network problem is temporary instability, it is possible to successfully obtain data by retrying.

[0064] The server may be temporarily overloaded, undergoing maintenance or upgrades, and may be unable to respond to requests. In this case, you can successfully retrieve data by retrying the operation, such as retrying the retrywhen operator to re-execute the second observable object.

[0065] For example, you can retry the types of abnormal data such as error requests and authorization failures. When you get the response data for the error request, you can resend the network request. When authorization fails or the signature is wrong, you can jump back to the login page.

[0066] In an embodiment of the present application, it is also possible to determine whether the response data is the expected data. If the response data is unexpected data, that is, it is not the data desired by the network request, the application may crash if it is not processed. In this case, in order to improve the reliability of the application operation, the normal data returned can be converted into abnormal data through operators, such as the onErrorResumeNext (continue to the next when an error occurs) operator, so that global error exception processing can be performed, including determining the error code and text description information corresponding to the unexpected data.

[0067] For example, the correspondence between the error code and text description information corresponding to the determined unexpected data may include: 400 Error Request, 401 Authorization Failure, 402 Signature Error, 403 Interface No Permission, 404 Request Not Allowed or 405 Parameter Error, etc.

[0068] By subscribing to the data of the second observable object, the subscriber can obtain unified error codes and text description information under different applications, different operations, and different protocols, thereby effectively adapting to the development needs of applications with different applications, different operations, and different protocols, and improving development efficiency.

[0069] Figure 4 A schematic diagram of network data processing provided by an embodiment of the present application. Figure 4 As shown, before the client sends a network request to the server, it can detect whether there is a network. If there is no network, a prompt message indicating that there is no network is sent to the user. In the case of a network, the global error conversion class can be inserted into the first observable object generated by the network request through the compose operator to obtain the second observable object. The error type conversion is performed through the second observable object.

[0070] When the response type is a normal response, that is, when the response data is normal data, the data can be transmitted normally to the downstream.

[0071] When the response type is an abnormal response, that is, when the response data is abnormal data, the do on error operator can be used in combination with throwable parsing to obtain the text description information of the corresponding abnormal response type and the corresponding error code, including abnormal response types such as 1101 network error, 1102 parsing error, 1103 connection failure, 1104 host exception, 1105 I / O exception, 1106 connection timeout, 1107 certificate verification failure, 500 server exception, and 1100 unknown error.

[0072] When the response data is unexpected data, the onErrorResumeNext operator can be used to convert the returned normal data into abnormal data, so that the error code and text description information corresponding to the unexpected data can be determined through global error exception processing, including 400 error request, 401 authorization failure, 402 signature error, 403 interface no permission, 404 request not allowed or 405 parameter error, etc.

[0073] When an access exception occurs and a pop-up box is needed to inform the user or a heavy operation is required, the retrywhen operator can be used to determine whether a heavy operation is required based on different error types. For example, when the response type is an error request, a retry operation can be performed. When the response type is an authorization failure or a signature error, a retry operation can be performed and the login page can be returned.

[0074] In the processing method of the network request in the embodiment of the present application, according to the first observable object generated by the network request, the global error conversion class is inserted into the first observable object through the combination operator to obtain the second observable object, and the response data of the network request is received through the second observable object. All errors are uniformly processed by the global error conversion class. No matter what error is returned by the network request, it can be processed by this conversion class, so that the developer does not need to nest multiple callbacks in the callback, which greatly reduces the amount of code development. When updating the response logic, only the global error conversion class needs to be updated, which is conducive to reducing maintenance costs and improving code readability.

[0075] It should be understood that the size of the serial numbers of the steps in the above embodiments does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0076] Figure 5 A schematic diagram of a network request processing device provided in an embodiment of the present application, the device comprising: A first observable object generating unit 501 is used to send a network request and obtain a first observable object generated by the network request; An inserting unit 502, configured to insert a global error conversion class into the first observable object through a combination operator to obtain a second observable object, wherein the global error conversion class is used for unified processing according to the type of the global error; The conversion processing unit 503 is used to receive the response data of the network request, and convert the response data through the global error conversion class to obtain the processing result corresponding to the response data.

[0077] Figure 5 The network request processing device shown in Figure 2The network request processing method shown corresponds to.

[0078] Figure 6 Schematic diagram of a network request processing device provided in an embodiment of the present application. Figure 6 As shown, the network request processing device 6 of this embodiment includes: a processor 60, a memory 61, and a computer program 62 stored in the memory 61 and executable on the processor 60, such as a network request processing program. When the processor 60 executes the computer program 62, the steps in the above-mentioned network request processing method embodiments are implemented. Alternatively, when the processor 60 executes the computer program 62, the functions of each module / unit in the above-mentioned device embodiments are implemented.

[0079] Exemplarily, the computer program 62 may be divided into one or more modules / units, which are stored in the memory 61 and executed by the processor 60 to complete the present application. The one or more modules / units may be a series of computer program instruction segments capable of completing specific functions, which are used to describe the execution process of the computer program 62 in the network request processing device 6.

[0080] The network request processing device may include, but is not limited to, a processor 60 and a memory 61. Those skilled in the art will appreciate that Figure 6 It is only an example of a network request processing device 6 and does not constitute a limitation of the network request processing device 6. It may include more or fewer components than shown in the figure, or a combination of certain components, or different components. For example, the network request processing device may also include input and output devices, network access devices, buses, etc.

[0081] The processor 60 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor, etc.

[0082] The memory 61 may be an internal storage unit of the network request processing device 6, such as a hard disk or memory of the network request processing device 6. The memory 61 may also be an external storage device of the network request processing device 6, such as a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, etc. equipped on the network request processing device 6. Further, the memory 61 may also include both an internal storage unit and an external storage device of the network request processing device 6. The memory 61 is used to store the computer program and other programs and data required by the network request processing device. The memory 61 may also be used to temporarily store data that has been output or is to be output.

[0083] The technicians in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional units and modules is used as an example for illustration. In practical applications, the above-mentioned function allocation can be completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiment can be integrated in a processing unit, or each unit can exist physically separately, or two or more units can be integrated in one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units. In addition, the specific names of the functional units and modules are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of this application. The specific working process of the units and modules in the above-mentioned system can refer to the corresponding process in the aforementioned method embodiment, which will not be repeated here.

[0084] In the above embodiments, the description of each embodiment has its own emphasis. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0085] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0086] In the embodiments provided in the present application, it should be understood that the disclosed devices / terminal equipment and methods can be implemented in other ways. For example, the device / terminal equipment embodiments described above are only schematic. For example, the division of the modules or units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0087] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0088] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0089] If the integrated module / unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the present application implements all or part of the processes in the above-mentioned embodiment method, and can also be completed by hardware related to computer program instructions. The computer program can be stored in a computer-readable storage medium, and the computer program can implement the steps of the above-mentioned various method embodiments when executed by the processor. Among them, the computer program includes computer program code, and the computer program code can be in source code form, object code form, executable file or some intermediate form. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording medium, U disk, mobile hard disk, disk, optical disk, computer memory, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), electric carrier signal, telecommunication signal and software distribution medium. It should be noted that the content contained in the computer-readable medium can be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electric carrier signals and telecommunication signals.

[0090] In addition, an embodiment of the present application also provides a computer program product, which, when executed on a computer, enables the computer to execute the methods in the above-mentioned implementation modes.

[0091] The embodiments described above are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, a person skilled in the art should understand that the technical solutions described in the aforementioned embodiments may still be modified, or some of the technical features may be replaced by equivalents. Such modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application, and should all be included in the protection scope of the present application.

Claims

1. A network request processing method, characterized in that: The method comprises: Send a network request and obtain a first observable object generated by the network request; Inserting a global error conversion class into the first observable object through a combination operator to obtain a second observable object, wherein the global error conversion class is used for unified processing according to the type of global errors; Receive response data of the network request, convert the response data through the global error conversion class, and obtain a processing result corresponding to the response data.

2. The method according to claim 1, characterized in that: Receiving response data of the network request, converting the response data through the global error conversion class, and obtaining a processing result corresponding to the response data, including: Receive response data of the network request through a base class, wherein the base class includes a status code, returned data, and a prompt; The global error conversion class converts the response data according to the status code, returned data and prompt included in the base class to obtain a processing result corresponding to the response data.

3. The method according to claim 2, characterized in that The global error conversion class converts the response data according to the status code, returned data and prompt included in the base class to obtain a processing result corresponding to the response data, including: Determine the response type corresponding to the status code of the base class according to a predetermined correspondence between the status code and the response type; According to the response type, the response data is converted by the global error conversion class to obtain a processing result corresponding to the response data.

4. The method according to claim 3, characterized in that According to the response type, the response data is converted by the global error conversion class to obtain a processing result corresponding to the response data, including: When the response type is a normal response, transmitting the returned data included in the base class to the downstream; When the response type is an abnormal response, the status code and prompt in the base class are mapped to the globally converted error code and text description information according to a preset mapping relationship to obtain the processing result corresponding to the response data.

5. The method according to claim 3, characterized in that: According to the response type, the response data is converted by the global error conversion class to obtain a processing result corresponding to the response data, including: When the response type is a type to be retried, determining to re-execute the second observable object according to a retry operator.

6. The method according to claim 5, characterized in that The type to be retried includes at least one of a network abnormality type and a server failure type.

7. The method according to claim 2, characterized in that: The global error conversion class converts the response data according to the status code, returned data and prompt included in the base class to obtain a processing result corresponding to the response data, including: When the global error conversion class determines that the returned data included in the base class is unexpected data, the returned data is converted into abnormal data; The error code and text description information included in the processing result of the returned data are determined according to the correspondence between the abnormal data and the error code and text description information after global conversion.

8. A network request processing device, characterized in that: The device comprises: A first observable object generating unit, configured to send a network request and obtain a first observable object generated by the network request; an insertion unit, configured to insert a global error conversion class into the first observable object through a combination operator to obtain a second observable object, wherein the global error conversion class is used for unified processing according to the type of the global error; The conversion processing unit is used to receive the response data of the network request, convert the response data through the global error conversion class, and obtain the processing result corresponding to the response data.

9. A network request processing device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the network request processing device implements the method according to any one of claims 1 to 7.

10. A computer program product comprising computer program instructions, characterized in that When the computer program is executed, the method according to any one of claims 1 to 7 is performed.

Images