A request processing method and device applied to an iOS terminal

Abstract

The application discloses a request processing method and device applied to an iOS terminal, and relates to the technical field of automatic programming. A specific implementation manner of the method comprises the following steps: in response to receiving a request generation instruction, determining a business type to which the request generation instruction belongs; from a plurality of pre-set business subclasses, searching for one or more target business subclasses matched with the business type and attribute information of each target business subclass, wherein each business subclass inherits a pre-set basic parent class, and a storage process and a retrieval process of attribute names included in the attribute information and attribute values included in the attribute information are declared in the business subclass; based on the basic parent class, the one or more target business subclasses and the attribute information of each target business subclass, assembling a business request, and sending the assembled business request to a server. The implementation manner can effectively reduce the request processing workload and complexity, and effectively improve the development efficiency of the business.

Description

Technical Field

[0001] This invention relates to the field of automatic programming technology, and in particular to a request processing method and apparatus for iOS terminals. Background Technology

[0002] Requests sent to servers by applications that rely on the iOS mobile operating system typically include a request header and a request body. The request headers and bodies for different iOS applications, or different business requests within the same iOS application, generally contain different request elements or parameters. Currently, different business requests require writing code based on interfaces provided by the iOS system; that is, separate business code needs to be written for each request. If logic or parameters are to be injected into business requests, the relevant code must be modified.

[0003] The existing approach of modifying the logic or parameters of business requests by modifying parts of the code can reduce the efficiency of business development. Furthermore, multiple people operating the code involved in business requests are prone to code logic conflicts, which increases the workload and complexity of request processing and will further negatively impact the efficiency of business development. Summary of the Invention

[0004] In view of this, embodiments of the present invention provide a request processing method and apparatus for iOS terminals, which can effectively reduce the workload and complexity of request processing, thereby effectively improving the development efficiency of business applications.

[0005] To achieve the above objectives, according to one aspect of the present invention, a request processing method applied to an iOS terminal is provided, comprising:

[0006] In response to receiving a request generation instruction, determine the service type to which the request generation instruction belongs;

[0007] From a set of pre-defined business subclasses, find one or more target business subclasses that match the business type and the attribute information of each target business subclass. Each business subclass inherits from a pre-defined base parent class. The business subclass declares the storage procedure and retrieval procedure for the attribute name and attribute value included in the attribute information.

[0008] Based on the base parent class, one or more target business subclasses, and the attribute information of each target business subclass, a business request is assembled and sent to the server.

[0009] Optionally, the step of finding one or more target business subclasses that match the business type and the attribute information of each target business subclass includes:

[0010] Find one or more first business subclasses corresponding to the request message header and / or one or more second business subclasses corresponding to the request message body that match the business type, along with the attribute information of each first business subclass and / or the attribute information of each second business subclass.

[0011] Optionally, assembling the service request includes:

[0012] Based on the request type indicated by the request generation instruction, the assembly format of the business request is determined, wherein the request type is a publish class for actively sending messages to the server or a response class for responding to the server.

[0013] From the base parent class and one or more target business subclasses including the second business subclass corresponding to the request message body, obtain the business logic of the request message body belonging to the request type and one or more first attribute names;

[0014] From the attribute information of the second business subclass included in the attribute information of the target business subclass, obtain one or more attribute values ​​of the first attribute name;

[0015] The business logic, along with one or more first attribute names and attribute values ​​in key-value pair form, are assembled into a message body that satisfies the assembly format.

[0016] The service request is obtained by assembling the message body and the message header determined by the request generation instruction.

[0017] Optionally, assembling the service request further includes:

[0018] Based on the portion of the base parent class that involves request message headers, the message header of the request generation instruction is determined;

[0019] or,

[0020] Based on the portion of the base parent class that involves the request message header, the second attribute name in the first business subclass corresponding to the request message header of one or more target business subclasses, and the attribute value of the second attribute name included in the attribute information of the target business subclass, the message header of the request generation instruction is determined.

[0021] Optionally, after obtaining the attribute values ​​of one or more of the first attribute names, and before assembling the business logic and one or more of the first attribute names and attribute values ​​in key-value pair form into a message body that satisfies the assembly format, the method further includes:

[0022] According to the request type indicated by the request generation instruction, the attribute value of each of the first attribute names obtained is verified.

[0023] The step of assembling the business logic and one or more first attribute names and attribute values ​​in key-value pair form into a message body that satisfies the assembly format includes:

[0024] The attribute value of the first attribute name that passes the verification and its corresponding first attribute name are assembled into the message body as key-value pairs.

[0025] Optionally, the above method further includes:

[0026] A new business subclass is constructed that inherits from the base parent class, so that the new business subclass can be used to change the attribute values ​​in the business request or add new attribute information to the business request.

[0027] Optionally, assembling the service request further includes:

[0028] The business request is assembled by calling the NSURLSession class of the iOS system through the aforementioned parent class.

[0029] Optionally, assembling the service request includes:

[0030] Intercept one or more of the target business subclasses and / or the attribute information of the target business subclasses, and replace the business logic and / or attribute information of the target business subclasses;

[0031] Assemble the replacement business logic and the replacement attribute information into the business request.

[0032] Optionally, assembling the service request further includes:

[0033] Identify whether one or more of the target business subclasses meet the interception conditions;

[0034] If the interception conditions are met, the step of intercepting one or more of the target business subclasses and / or the attribute information of the target business subclasses is performed.

[0035] If the interception conditions are not met, the step of assembling a business request based on the base parent class, one or more target business subclasses, and the attribute information of each target business subclass is directly executed.

[0036] Optionally, after assembling the service request and before sending the assembled service request to the server, the method further includes:

[0037] Intercept the service request and process the intercepted service request;

[0038] Sending the assembled business request to the server includes: sending the processed business request to the server.

[0039] Optionally, processing the intercepted service requests includes:

[0040] Modify the business logic and / or attribute information included in the intercepted business requests;

[0041] And / or,

[0042] The encryption / decryption function is invoked to encrypt the intercepted business requests.

[0043] Optionally, the above method further includes:

[0044] Receive and intercept data sent by the server corresponding to the business request;

[0045] The intercepted data is processed, and the processed data is provided to the user.

[0046] Secondly, embodiments of the present invention provide a request processing apparatus for an iOS terminal, comprising: a determining module, a request assembly module, and an interaction module, wherein...

[0047] The determining module, in response to receiving a request generation instruction, determines the service type to which the request generation instruction belongs;

[0048] The request assembly module is used to search for one or more target business subclasses that match the business type from a plurality of pre-set business subclasses, as well as the attribute information of each target business subclass. Each business subclass inherits from a pre-set base parent class, and the business subclass declares a storage procedure and a retrieval procedure for the attribute names and attribute values ​​included in the attribute information. Based on the base parent class, one or more target business subclasses, and the attribute information of each target business subclass, a business request is assembled.

[0049] The interaction module is used to send the assembled business request to the server.

[0050] According to another aspect of the present invention, an electronic device is also provided, comprising:

[0051] One or more processors;

[0052] Storage device for storing one or more programs.

[0053] When the one or more programs are executed by the one or more processors, the one or more processors implement the method described in any of the above embodiments.

[0054] According to another aspect of the present invention, a computer-readable medium is also provided, on which a computer program is stored, which, when executed by a processor, implements the methods described in any of the above embodiments.

[0055] According to another aspect of the present invention, a computer program product is also provided, including a computer program that, when executed by a processor, implements the methods described in any of the above embodiments.

[0056] One embodiment of the above invention has the following advantages or beneficial effects: By using the structure of business subclasses inheriting from the base parent class, requests for different businesses can be generated based on their respective business subclasses. That is, in response to receiving a request generation instruction, the business type to which the request generation instruction belongs is determined; from a set of multiple pre-defined business subclasses, one or more target business subclasses matching the business type and the attribute information of each target business subclass are searched; then, by generating the base parent class required for the request, one or more target business subclasses, and the stored procedures and retrieval procedures for the attribute names and attribute values ​​declared in each target business subclass, the business request is assembled. This allows users to construct business subclasses that inherit from the base parent class. Since the business subclasses declare the attribute names and attribute values, the stored procedures and retrieval procedures allow users to configure the attribute information of the business subclass at any location or time. That is, when users need to construct new business requests or add parameters to requests, they can add business subclasses or add attribute information to business subclasses at any time or location without modifying the request generation code and business logic, thereby effectively reducing the workload and complexity of request processing and effectively improving the development efficiency of the business.

[0057] The further effects of the aforementioned unconventional alternative methods will be explained below in conjunction with specific implementation methods. Attached Figure Description

[0058] The accompanying drawings are provided to better understand the invention and are not intended to unduly limit the scope of the invention. Wherein:

[0059] Figure 1 This is an exemplary system architecture diagram in which embodiments of the present invention can be applied;

[0060] Figure 2This is a schematic diagram of the main flow of a request processing method applied to an iOS terminal according to an embodiment of the present invention;

[0061] Figure 3 This is a structural diagram illustrating the relationship between the base parent class and the business subclass according to an embodiment of the present invention;

[0062] Figure 4 This is a schematic diagram of the main process of assembling a service request according to an embodiment of the present invention;

[0063] Figure 5 This is a schematic diagram of the main process for assembling the message header in a service request according to an embodiment of the present invention;

[0064] Figure 6 This is a structural diagram illustrating the relationship between the basic parent class, the business subclasses related to the message body, and the subclasses related to the message header according to an embodiment of the present invention.

[0065] Figure 7 This is a schematic diagram of the main process of assembling a service request according to an embodiment of the present invention;

[0066] Figure 8 This is a schematic diagram of another main process for assembling a service request according to another embodiment of the present invention;

[0067] Figure 9 This is a schematic diagram of the main process for intercepting and processing assembled requests according to an embodiment of the present invention;

[0068] Figure 10 This is a schematic diagram of another main process for intercepting and processing assembled requests according to an embodiment of the present invention;

[0069] Figure 11 This is a schematic diagram of the main flow of a request processing method applied to an iOS terminal according to another embodiment of the present invention;

[0070] Figure 12 This is a schematic diagram of the main modules of a request processing device applied to an iOS terminal according to an embodiment of the present invention;

[0071] Figure 13 This is a schematic diagram of the structure of a computer system suitable for implementing the terminal device of the present invention. Detailed Implementation

[0072] The following description, in conjunction with the accompanying drawings, illustrates exemplary embodiments of the present invention, including various details to aid understanding. These details should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the invention. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0073] The request processing method applied to an iOS terminal in this embodiment of the invention is generally implemented by a client installed on the iOS terminal. Correspondingly, the request processing device applied to the iOS terminal is generally a part of the client installed on the iOS terminal or a functional module / functional unit.

[0074] Figure 1 An exemplary system architecture 100 is shown, to which the request processing method or the request processing apparatus for an iOS terminal, according to embodiments of the present invention, can be applied.

[0075] like Figure 1 As shown, the system architecture 100 may include terminal devices 101, 102, and 103, a network 104, and a server 105. The terminal devices 101, 102, and 103 are equipped with clients that implement the request processing method for iOS terminals provided in this embodiment of the invention. The network 104 serves as a medium for providing communication links between the terminal devices 101, 102, and 103 and the server 105. The network 104 may include various connection types, such as wired or wireless communication links, or fiber optic cables, etc.

[0076] Users can use terminal devices 101, 102, and 103 to interact with server 105 via network 104, sending requests for services or responding to server 105. Various communication client applications can be installed on terminal devices 101, 102, and 103, such as web browsers, search applications, instant messaging tools, email clients, and social media platforms (for example only).

[0077] Upon receiving a request generation instruction, terminal devices 101, 102, and 103 assemble a service request based on a preset base parent class, one or more target service subclasses matching the request generation instruction, and the stored procedures and retrieval procedures for the attribute names and attribute values ​​declared by each target service subclass. They then send the service request to server 105. This service request can be a request actively sent by terminal devices 101, 102, and 103 to server 105 requesting server 105 to execute a service, or it can be a response from terminal devices 101, 102, and 103 to information sent by server 105.

[0078] Terminal devices 101, 102, and 103 can be various electronic devices with displays and web browsing capabilities that are equipped with the iOS system, including but not limited to smartphones, tablets, laptops, and desktop computers.

[0079] Server 105 can be a server that provides various services, such as a backend management server that supports the services of terminal devices 101, 102, and 103 (for example only). The backend management server can process the requests based on terminal devices 101, 102, and 103, and return the processing results to the terminal devices.

[0080] It should be noted that the request processing method for iOS terminals provided in this embodiment of the invention is generally executed by terminal devices 101, 102, and 103. Correspondingly, the request processing device for iOS terminals is generally located in terminal devices 101, 102, and 103.

[0081] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0082] Figure 1 The request handling method shown, implemented on a terminal device with iOS installed, may include... Figure 2 The main flow of a request processing method applied to an iOS terminal according to an embodiment of the present invention is shown.

[0083] Figure 2 This is a schematic diagram illustrating the main flow of a request processing method applied to an iOS terminal according to an embodiment of the present invention. Figure 2 As shown, the request processing method applied to the iOS terminal may include the following steps:

[0084] Step S201: In response to receiving the request generation instruction, determine the service type to which the request generation instruction belongs;

[0085] The received request to generate an instruction can be an instruction generated by the terminal device in response to information sent by the server, caused by the user pressing a button on the page or by the terminal device responding to information sent by the server. This instruction enables the terminal device to generate a service request based on the instruction.

[0086] This business type can be categorized based on the corresponding business subclass or on specific business functions. For example, it could be a bill inquiry business type, an invoice receipt business type, a repayment business type, a payment business type, an order placement business type, or a customer service business type. This business type can be categorized based on user needs or the settings of the business subclass.

[0087] Step S202: From a set of pre-defined business subclasses, find one or more target business subclasses that match the business type and the attribute information of each target business subclass. Each business subclass inherits from a pre-defined base parent class. The business subclass declares the attribute names and attribute values ​​included in the attribute information, as well as the storage and retrieval procedures.

[0088] The business subclasses are implemented in Objective-C and declare properties in the form of properties (which are a type of class property structure provided by iOS that specifies the types of properties, such as NSString for strings and NSArray for arrays) to implement specific business functions such as bill inquiry, billing, repayment, and payment.

[0089] The base parent class provides the necessary basic information for generating business requests for various business subclasses.

[0090] The relationship between the base parent class and the business subclass can be as follows: Figure 3 As shown. Figure 3 Several business subclasses are provided as an example, namely business subclass 1, 2, 3, ..., N. These business subclasses 1, 2, 3, ..., N inherit from the base parent class, and each business subclass 1, 2, 3, ..., N is relatively independent. That is, users can add new business subclasses to enable the terminal device to generate new business requests to meet the needs of request expansion.

[0091] By declaring stored procedures and retrieval procedures in business subclasses that include attribute names and attribute values, users can set attribute values ​​for business subclasses at any point in time and store the configured attribute values ​​in any location, making business configuration flexible.

[0092] In addition, by configuring business subclasses to implement new business requests, users only need to focus on their own configured business subclasses, without having to worry about the global business code logic, which effectively improves the development of various types of business requests.

[0093] Step S203: Based on the base parent class, one or more target business subclasses, and the attribute information of each target business subclass, assemble a business request and send the assembled business request to the server.

[0094] This step mainly involves encapsulating the attribute names and values ​​of the attribute information, along with the business logic required by the request, into a request containing a message header and a message body, based on the processing logic given by the base parent class and one or more target business subclasses, and the attribute information declared by the base parent class and one or more target business subclasses.

[0095] exist Figure 2 In the illustrated embodiment, the structure of business subclasses inheriting from the base parent class allows requests for different businesses to be generated based on their respective business subclasses. Specifically, in response to a received request generation instruction, the business type to which the instruction belongs is determined. From a set of pre-defined business subclasses, one or more target business subclasses matching the business type, along with the attribute information of each target business subclass, are searched. Then, by generating the base parent class required for the request, one or more target business subclasses, and the stored procedures and retrieval procedures for the attribute names and values ​​declared in each target business subclass, a business request is assembled. This allows users to construct business subclasses that inherit from the base parent class. Because the business subclasses contain the attribute names and values ​​declared in their stored procedures and retrieval procedures, users can configure the attribute information of the business subclass at any location or time. That is, when users need to construct new business requests or add parameters to requests, they can add business subclasses or add attribute information to business subclasses at any time or location without modifying the request generation code or business logic. This effectively reduces the workload and complexity of request processing, thereby significantly improving business development efficiency.

[0096] In addition, by constructing different business subclasses and declaring the attribute information of the business subclasses, it is convenient for different staff to modify and maintain business requests, so as not to cause conflicts between different staff to modify and maintain business requests. At the same time, the logic required for request generation is decoupled from the business code, avoiding modification of the business code.

[0097] In this embodiment of the invention, the specific implementation of finding one or more target business subclasses matching the business type and the attribute information of each target business subclass may include: finding one or more first business subclasses corresponding to the request message header and / or one or more second business subclasses corresponding to the request message body, and the attribute information of each first business subclass and / or each second business subclass. The first and second business subclasses may belong to the same business subclass or different business subclasses. By separately finding one or more first business subclasses corresponding to the message header and one or more second business subclasses corresponding to the request message body, the message header and message body can be configured separately, thereby decoupling the message body and message header, facilitating isolated configuration of the message header and message body, and further improving the configurability of the business generation request.

[0098] In embodiments of the present invention, such as Figure 4 As shown, the specific implementation method for assembling a service request as described above may include the following steps:

[0099] Step S401: Determine the assembly format of the business request according to the request type indicated by the request generation instruction, wherein the request type is a publish class used to actively send messages to the server or a response class used to respond to the server;

[0100] Since different request types have different formats, determining the assembly format of business requests ensures that the assembled requests meet server requirements. This allows the server to accurately determine whether a request is a publish or respond request, and to accurately extract the required parameters and business logic from the request. Furthermore, assembling requests according to the specified format ensures that the assembled requests conform to existing request protocols for client-server interaction, reducing intrusive modifications to the interaction between the client and server.

[0101] Step S402: Obtain the business logic of the request message body belonging to the request type and one or more first attribute names from the base parent class and the second business subclasses corresponding to the request message body included in one or more target business subclasses;

[0102] Step S403: Obtain the attribute values ​​of one or more first attribute names from the attribute information of the second business subclass included in the attribute information of the target business subclass;

[0103] Step S404: Assemble the business logic and one or more first attribute names and attribute values ​​in key-value pair form into a message body that meets the assembly format;

[0104] In this key-value pair, the first attribute name is 'key', and its corresponding attribute value is 'value'. Through the stored procedures and retrieval procedures for the attribute names and values ​​declared in the aforementioned business subclasses, as well as one or more first attribute names and values ​​in key-value pair form, different attributes of the business subclass can be assigned values ​​multiple times before the request is initiated. Values ​​can also be assigned to the same attribute, with the new value replacing the old one. This storage and retrieval process for the attribute names and values ​​declared in the business subclasses, along with one or more first attribute names and values ​​in key-value pair form, allows coders to more clearly view the fields contained in each message body and makes modification easier.

[0105] Step S405: Assemble the message body and the message header determined for the request generation instruction to obtain the business request.

[0106] Assembling the business request may further include: calling the iOS system's NSURLSession class through the base parent class to assemble the business request. This NSURLSession class is a commonly used network inner class existing in the iOS system itself. This application's base parent class generates requests by calling the iOS system's NSURLSession class, which not only reduces the complexity of user-built classes but also reduces intrusive modifications to the iOS system's request generation. That is, it relies on the iOS system's built-in NSURLSession class to achieve decoupling between different business requests and between business requests and business logic code, while better aligning with the needs of the iOS system.

[0107] There are two ways to assemble the message header in a business request.

[0108] The first method for assembling the message header in a business request involves determining the message header of the request generation instruction based on the parts of the request message header included in the base parent class.

[0109] like Figure 5 The structure diagram shown includes a base parent class and subclasses a and b for generating message headers, where subclasses a and b inherit from the base parent class. This base parent class contains the portion corresponding to the message header; therefore, for requests that do not require changes to the message header, the message header can be processed solely through the base parent class to obtain the request's message header.

[0110] The second method for assembling the message header in a business request is as follows: Based on the part of the base parent class that involves the request message header, the second attribute name in the first business subclass corresponding to the request message header, and the attribute value of the second attribute name included in the attribute information of the target business subclass, the message header of the request generation instruction is determined.

[0111] for example, Figure 5 The subclasses a and b shown are both first business subclasses corresponding to the request message header. The message header of subclass a is processed through the base parent class and subclass a to obtain the message header of the business request corresponding to subclass a. The message header of subclass b is processed through the base parent class, i.e. subclass b, to obtain the message header of the business request corresponding to subclass b.

[0112] The above methods can meet the needs of different message headers.

[0113] It is worth noting that the first business subclass of the message header and the second business subclass of the message body can belong to the same business subclass or different business subclasses.

[0114] In summary, the message header can be obtained from a base parent class or from a subclass that inherits from the base parent class. This subclass may or may not contain the logic methods that implement the message body. The following example... Figure 6 The diagram shows requests for service A, service B, and service C obtained through different methods.

[0115] For example, for request A, its message header is obtained by processing the message header in the base parent class, and the message body is obtained by the business subclass A, which inherits from the base parent class. Request A is obtained by assembling the message header obtained from the base parent class and the message body obtained from the business subclass A. For request B, its message header and message body are obtained by processing the message header and message body in the business subclass B, which inherits from the base parent class. For request C, its message header is obtained by processing the message header in the message header subclass C', and the message body is obtained by processing the message body in the business subclass C, which inherits from the base parent class. This implementation can meet the generation requirements of different business requests.

[0116] In this embodiment of the invention, after obtaining the attribute values ​​of one or more first attribute names, before assembling the business logic and one or more first attribute names and attribute values ​​in key-value pairs into a message body that satisfies the assembly format, the method may further include: validating the attribute value of each obtained first attribute name according to the request type indicated by the request generation instruction; correspondingly, a specific implementation of assembling the business logic and one or more first attribute names and attribute values ​​in key-value pairs into a message body that satisfies the assembly format may include: assembling the attribute values ​​of the validated first attribute names and their corresponding first attribute names into the message body in key-value pairs. For example, the validation may involve determining whether the string length is greater than 1, or whether there are values ​​in an array. Validation can exclude attribute values ​​that do not conform to the rules or format, and the remaining attribute values ​​that conform to the rules or format can be used to assemble the message body, ensuring that all parameters in the message body can be recognized by the server, and avoiding the problem of request failure caused by attribute values ​​that do not conform to the format or rules still being assembled into the request.

[0117] In embodiments of the present invention, such as Figure 7 As shown, the specific implementation method for assembling a service request as described above may include the following steps:

[0118] Step S701: Intercept one or more target business subclasses and / or the attribute information of the target business subclasses, and replace the business logic and / or attribute information of the target business subclasses;

[0119] Step S702: Assemble the replacement business logic and the replacement attribute information into the business request.

[0120] This involves intercepting the target business subclass and / or its attribute information before assembling the business request, replacing the original target business subclass and / or its attribute information to modify the business request. This avoids modifying the target business subclass itself, further improving the flexibility of business request updates. Simultaneously, by using interception, modifications can be injected outside the business code, without conflicting with business development, reducing dependence on business development.

[0121] In embodiments of the present invention, such as Figure 8 As shown, the specific implementation method for assembling a service request as described above may further include the following steps:

[0122] Step S801: Identify whether one or more target business subclasses meet the interception conditions. If the interception conditions are met, proceed to step S802; if the interception conditions are not met, proceed to step S803.

[0123] The interception condition can be set according to user needs, such as intercepting a certain type of business subclass or intercepting a business subclass containing a certain attribute, so as to selectively intercept the target business subclass and / or the attribute information of the target business subclass.

[0124] Step S802: Execute the step of intercepting one or more target business subclasses and / or the attribute information of the target business subclasses;

[0125] Step S803: Directly execute the step of assembling a business request based on the base parent class, one or more target business subclasses, and the attribute information of each target business subclass.

[0126] Through this Figure 8 The provided solution intercepts target business subclasses according to user-defined interception conditions, thereby avoiding intrusive modifications to the original business subclasses and ensuring the non-intrusive scalability of the request generation logic.

[0127] In this embodiment of the invention, after assembling the business request, the method may further include: intercepting the business request and processing the intercepted business request; and sending the processed business request to the server. This step can be achieved by setting an interceptor to intercept the business request. Intercepting the business request and performing interception injection modifications outside the business code does not conflict with business development and facilitates operation and maintenance by multiple users.

[0128] Specifically, the specific implementation methods for processing the intercepted service requests described above may include: modifying the business logic and / or attribute information included in the intercepted service requests. For example... Figure 9 As shown, the business layer initiates a request based on business data and the business request assembled in the above embodiments. After intercepting the request, the interceptor modifies or adds parameters in the request and resends the modified or added parameters to the server. After receiving the data returned by the server, the interceptor can also intercept the data returned by the server to modify or format the data. The modified or formatted data is then processed by the business layer. This process reduces the data coupling between the business layer and the server. Even if the server can return data in any format, the interceptor can modify the server's data into a format that can be read by the business layer.

[0129] Furthermore, the specific implementation method for processing the intercepted service requests described above may include: encrypting the intercepted service requests by calling an encryptor / decryptor. Specifically, for example... Figure 10As shown, after intercepting the assembled request, the interceptor sends it to the encryption / decryption unit. The encryption / decryption unit encrypts the request and then sends the encrypted request to the server. Upon receiving data from the server, the interceptor sends this data back to the encryption / decryption unit for decryption and then sends the decrypted data to the business layer. By setting up the encryption / decryption unit, the process of encrypting and decrypting the request is decoupled from the process of generating the request, preventing any disruption to the business code. Furthermore, different encryption / decryption logic can be chosen to reduce the complexity of request processing.

[0130] It is worth noting that the encryption and decryption methods used in the encryption and decryption unit are determined through negotiation between the client and the server, and are not limited here.

[0131] like Figure 9 and Figure 10 As shown, the above method may further include: receiving and intercepting data sent by the server corresponding to the business request; processing the intercepted data; and providing the processed data to the user.

[0132] Furthermore, the above method may also include: constructing new business subclasses that inherit from the base parent class, so as to modify attribute values ​​in business requests or add new attribute information to business requests through the new business subclasses, thereby enabling the generation of requests for different business types.

[0133] In another embodiment of the invention, such as Figure 11 As shown, another request processing method provided for iOS terminals may include the following steps:

[0134] Step S1100: Construct multiple business subclasses that inherit from the base parent class;

[0135] Step S1101: In response to receiving the request generation instruction, determine the service type to which the request generation instruction belongs;

[0136] Step S1102: From a set of pre-defined business subclasses, find one or more first business subclasses corresponding to the request message header and / or one or more second business subclasses corresponding to the request message body that match the business type, as well as the attribute information of each first business subclass and / or the attribute information of each second business subclass.

[0137] Each business subclass declares the stored procedures and retrieval procedures for the attribute names and attribute values ​​included in the attribute information.

[0138] Step S1103: Determine the assembly format of the business request according to the request type indicated by the request generation instruction;

[0139] The request type is either a publish class used to actively send messages to the server or a response class used to respond to the server.

[0140] Step S1104: Based on the part of the base parent class that involves the request message header, the second attribute name in one or more first business subclasses, and the attribute value of the second attribute name included in the attribute information of the first business subclass, determine the message header of the request generation instruction.

[0141] Step S1104 can also determine the request generation instruction header based on the part of the request message header included in the base parent class.

[0142] Step S1105: Identify whether one or more second business subclasses meet the interception conditions; if the interception conditions are met, proceed to step S1106; if the interception conditions are not met, proceed to step S1107.

[0143] Step S1106: Intercept one or more second business subclasses and / or attribute information of the second business subclasses, and replace the business logic and / or attribute information of the second business subclasses, then execute step S1109;

[0144] Step S1107: Obtain the business logic of the request message body belonging to the request type and one or more first attribute names from the base parent class and one or more second business subclasses corresponding to the request message body;

[0145] Step S1108: Obtain the attribute values ​​of one or more first attribute names from the attribute information of the second business subclass;

[0146] Step S1109: Verify the attribute value of each first attribute name obtained according to the request type indicated by the request generation instruction;

[0147] Step S1110: Assemble the attribute values ​​of the first attribute names that have passed the verification and their corresponding first attribute names in key-value pairs to form a message body that meets the assembly format;

[0148] Step S1111: Assemble the message body and the message header determined for the request generation instruction to obtain the business request;

[0149] Step S1112: Intercept the business request through the interceptor, and modify the business logic and / or attribute information included in the intercepted business request;

[0150] Step S1113: Call the encryptor / decryptor to encrypt the intercepted business request;

[0151] Step S1114: Send the encrypted business request to the server;

[0152] Step S1115: Receive and intercept data sent by the server corresponding to the business request;

[0153] Step S1116: Decrypt the intercepted data and provide the decrypted data to the user.

[0154] It is worth noting that the above Figure 11 The given embodiment is one way to generate a request and receive the data corresponding to the request. Other combinations of steps that include this embodiment are also within the scope of protection of this application. For example, directly executing step S1107 after executing step S1104, or directly sending the assembled request to the server after executing step S1111, are all within the scope of protection of this application.

[0155] like Figure 12 As shown, this embodiment of the invention provides a request processing device 1200 for an iOS terminal. The request processing device 1200 may include: a determining module 1201, a request assembly module 1202, and an interaction module 1203.

[0156] Module 1201 determines the service type to which the request generation instruction belongs in response to receiving the request generation instruction.

[0157] The request assembly module 1202 is used to find one or more target business subclasses that match the business type from a set of pre-defined business subclasses, as well as the attribute information of each target business subclass. Each business subclass inherits from a pre-defined base parent class, and the business subclass declares the stored procedures and retrieval procedures for the attribute names and attribute values ​​included in the attribute information. Based on the base parent class, one or more target business subclasses, and the attribute information of each target business subclass, a business request is assembled.

[0158] Interaction module 1203 is used to send the assembled business request to the server.

[0159] In this embodiment of the invention, the request assembly module 1202 is used to find one or more first business subclasses corresponding to the request message header and / or one or more second business subclasses corresponding to the request message body that match the business type, as well as the attribute information of each first business subclass and / or the attribute information of each second business subclass.

[0160] In this embodiment of the invention, the request assembly module 1202 is further configured to determine the assembly format of the business request according to the request type indicated by the request generation instruction, wherein the request type is a publish class for actively sending messages to the server or a response class for responding to the server; obtain the business logic of the request message body belonging to the request type and one or more first attribute names from the second business subclasses corresponding to the request message body included in the base parent class and one or more target business subclasses; obtain the attribute values ​​of one or more first attribute names from the attribute information of the second business subclass included in the attribute information of the target business subclass; assemble the business logic and one or more first attribute names and attribute values ​​in key-value pair form to form a message body that satisfies the assembly format; assemble the message body and the message header determined for the request generation instruction to obtain the business request.

[0161] In this embodiment of the invention, the request assembly module 1202 is further configured to determine the message header of the request generation instruction based on the part of the request message header included in the basic parent class.

[0162] In this embodiment of the invention, the request assembly module 1202 is further configured to determine the message header of the request generation instruction based on the portion of the base parent class that involves the request message header, the second attribute name in the first business subclass corresponding to the request message header included in one or more target business subclasses, and the attribute value of the second attribute name included in the attribute information of the target business subclass.

[0163] In this embodiment of the invention, the request assembly module 1202 is further configured to verify the attribute value of each obtained first attribute name according to the request type indicated by the request generation instruction; and assemble the attribute value of the verified first attribute name and its corresponding first attribute name into the message body in the form of key-value pairs.

[0164] In this embodiment of the invention, the request assembly module 1202 is further configured to receive a new business subclass constructed by the user that inherits from the base parent class, so as to change the attribute values ​​in the business request or add new attribute information to the business request through the new business subclass.

[0165] In this embodiment of the invention, the request assembly module 1202 is further used to assemble the business request by calling the NSURLSession class of the iOS system through the basic parent class.

[0166] In embodiments of the present invention, such as Figure 12 As shown, the request processing device 1200 may further include: a first interceptor 1204, wherein,

[0167] The first interceptor 1204 is used to intercept one or more target business subclasses and / or the attribute information of the target business subclasses, and replace the business logic and / or attribute information of the target business subclasses.

[0168] The request assembly module 1202 is further used to assemble the business logic replaced by the first interceptor 1204 and the replaced attribute information into the business request.

[0169] In this embodiment of the invention, the first interceptor 1204 is used to identify whether one or more target business subclasses meet the interception conditions; if the interception conditions are met, the first interceptor performs the step of intercepting one or more target business subclasses and / or the attribute information of the target business subclasses; if the interception conditions are not met, the first interceptor triggers the request assembly module 1202.

[0170] The request assembly module 1202 is further configured to, upon receiving a trigger from the first interceptor 1204, directly execute the step of assembling a business request based on the base parent class, one or more target business subclasses, and the attribute information of each target business subclass.

[0171] In this embodiment of the invention, the request processing device 1200 may further include: a second interceptor 1205, wherein,

[0172] The second interceptor 1205 is used to intercept business requests and process the intercepted business requests;

[0173] The interaction module 1203 is used to send the processed business request to the server.

[0174] In this embodiment of the invention, the second interceptor 1205 is further configured to modify the business logic and / or attribute information included in the intercepted business request.

[0175] In embodiments of the present invention, such as Figure 12 As shown, the request processing device 1200 may further include: an encryption / decryption unit 1206, wherein,

[0176] The second interceptor 1205 is further used to call the encryptor 1206 to encrypt the intercepted business requests.

[0177] The following is for reference. Figure 13 It shows a schematic diagram of the structure of a computer system 1300 suitable for implementing a terminal device of the present invention. Figure 13 The terminal device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0178] like Figure 13As shown, the computer system 1300 includes a central processing unit (CPU) 1301, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 1302 or programs loaded from storage section 1308 into random access memory (RAM) 1303. The RAM 1303 also stores various programs and data required for the operation of the system 1300. The CPU 1301, ROM 1302, and RAM 1303 are interconnected via a bus 1304. An input / output (I / O) interface 1305 is also connected to the bus 1304.

[0179] The following components are connected to I / O interface 1305: an input section 1306 including a keyboard, mouse, etc.; an output section 1307 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 1308 including a hard disk, etc.; and a communication section 1309 including a network interface card such as a LAN card, modem, etc. The communication section 1309 performs communication processing via a network such as the Internet. A drive 1310 is also connected to I / O interface 1305 as needed. Removable media 1311, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 1310 as needed so that computer programs read from them can be installed into storage section 1308 as needed.

[0180] In particular, according to embodiments disclosed in this invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 1309, and / or installed from removable medium 1311. When the computer program is executed by central processing unit (CPU) 1301, it performs the functions defined above in the system of this invention.

[0181] It should be noted that the computer-readable medium shown in this invention can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this invention, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0182] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0183] The modules described in the embodiments of the present invention can be implemented in software or hardware. The described modules can also be housed in a processor; for example, a processor can be described as including a determining module, a request assembly module, and an interaction module. The names of these modules do not necessarily limit the module itself; for example, the determining module can also be described as "a module that determines the business type to which the request generation instruction belongs."

[0184] In another aspect, the present invention also provides a computer-readable medium, which may be included in the device described in the above embodiments; or it may exist independently and not assembled into the device. The computer-readable medium carries one or more programs, which, when executed by the device, cause the device to include: in response to receiving a request generation instruction, determining the business type to which the request generation instruction belongs; searching from a plurality of pre-set business subclasses for one or more target business subclasses matching the business type and attribute information of each target business subclass, wherein each business subclass inherits from a pre-set base parent class, and the business subclass declares a storage procedure and a retrieval procedure for the attribute names and attribute values ​​included in the attribute information; assembling a business request based on the base parent class, one or more target business subclasses, and the attribute information of each target business subclass, and sending the assembled business request to a server.

[0185] In another aspect, embodiments of the present invention also provide a computer program product, including a computer program that, when executed by a processor, implements the methods described in any of the above embodiments.

[0186] According to the technical solution of the present invention, by using a structure setting where business subclasses inherit from a base parent class, requests for different businesses can be generated based on their respective business subclasses. Specifically, in response to receiving a request generation instruction, the business type to which the request generation instruction belongs is determined. From a set of pre-defined business subclasses, one or more target business subclasses matching the business type and the attribute information of each target business subclass are searched. Then, by generating the base parent class required for the request, one or more target business subclasses, and the stored procedures and retrieval procedures for the attribute names and attribute values ​​declared in each target business subclass, a business request is assembled. This allows users to construct business subclasses that inherit from the base parent class. Since the business subclasses declare the attribute names and attribute values, the stored procedures and retrieval procedures allow users to configure the attribute information of the business subclass at any location or time. That is, when users need to construct new business requests or add parameters to requests, they can add business subclasses or add attribute information to business subclasses at any time or location without modifying the request generation code or business logic. This effectively reduces the workload and complexity of request processing, thereby effectively improving business development efficiency.

[0187] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can occur depending on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A request processing method applied to an iOS terminal, characterized in that, The application comprises the following steps: generating instructions in response to receiving a request, determining the business type to which the request generating instructions belong; finding one or more target business sub-classes and attribute information of each target business sub-class matching the business type from a plurality of pre-set business sub-classes, wherein each business sub-class inherits a pre-set basic parent class, and the storage process and retrieval process of the attribute name and attribute value included in the attribute information are declared in the business sub-class; assembling a business request based on the basic parent class, one or more target business sub-classes and attribute information of each target business sub-class, and sending the assembled business request to the server; the assembled business request comprises the following steps: determining the assembly format of the business request according to the request type indicated by the request generating instructions, wherein the request type is a publishing type for actively sending a message to the server or a response type for responding to the server; obtaining the business logic of the request message body and one or more first attribute names belonging to the request type from the basic parent class and the second business sub-class corresponding to the request message body included in one or more target business sub-classes; obtaining the attribute values of one or more first attribute names from the attribute information of the second business sub-class included in the attribute information of the target business sub-class; assembling the business logic and one or more first attribute names and attribute values in the form of key-value pairs into a message body that meets the assembly format; assembling the message body and the message header determined for the request generating instructions to obtain a business request.

2. The method of claim 1, wherein, The finding of one or more target business sub-classes and attribute information of each target business sub-class matching the business type comprises the following steps: finding one or more first business sub-classes corresponding to the request message header and / or one or more second business sub-classes corresponding to the request message body, attribute information of each first business sub-class and / or attribute information of each second business sub-class matching the business type.

3. The method of claim 1, wherein, The assembled business request further comprises the following steps: determining the message header of the request generating instructions based on the part related to the request message header included in the basic parent class; or determining the message header of the request generating instructions based on the part related to the request message header included in the basic parent class, the second attribute name in the first business sub-class corresponding to the request message header included in one or more target business sub-classes, and the attribute value of the second attribute name included in the attribute information of the target business sub-class.

4. The method of claim 1, wherein, After obtaining the attribute values of one or more first attribute names, before assembling the business logic and one or more first attribute names and attribute values in the form of key-value pairs into a message body that meets the assembly format, the method further comprises the following steps: verifying the attribute value of each first attribute name according to the request type indicated by the request generating instructions; The assembling the business logic and one or more first attribute names and attribute values in the form of key-value pairs to meet the assembling format of the message body comprises: Assembling the attribute values of the first attribute names that pass the verification and their corresponding first attribute names in the form of key-value pairs to the message body.

5. The method of claim 1, wherein, Further comprising: Building a new business subclass that inherits the basic parent class to change the attribute values in the business request or add new attribute information to the business request through the new business subclass.

6. The method of claim 1, wherein, The assembling the business request further comprises: Calling the NSURLSession class of the iOS system through the basic parent class to assemble the business request.

7. The method of claim 1, wherein, The assembling the business request comprises: Intercepting one or more target business subclasses and / or attribute information of the target business subclasses, and replacing the business logic and / or attribute information of the target business subclasses; Assembling the replaced business logic and attribute information to the business request.

8. The method of claim 7, wherein, The assembling the business request further comprises: Identifying whether one or more target business subclasses meet the interception condition; In the case of meeting the interception condition, performing the step of intercepting one or more target business subclasses and / or attribute information of the target business subclasses; In the case of not meeting the interception condition, directly performing the step of assembling the business request based on the basic parent class, one or more target business subclasses, and attribute information of each target business subclass.

9. The method of claim 1, wherein, After the assembling the business request, further comprising: Intercepting the business request and processing the intercepted business request; The sending the assembled business request to the server comprises sending the processed business request to the server.

10. The method of claim 9, wherein, The processing the intercepted business request comprises: Modifying the business logic and / or attribute information included in the intercepted business request; And / or, Calling the encryptor to encrypt the intercepted business request.

11. The method according to any one of claims 1, 9 and 10, characterized in that, Further comprising: Receiving and intercepting the data corresponding to the business request sent by the server; Processing the intercepted data and providing the processed data to the user.

12. A request processing apparatus applied to an iOS terminal, characterized by, Comprising: A determination module, a request assembling module, and an interaction module, wherein The determination module determines the business type to which the request generation instruction belongs in response to receiving the request generation instruction; The request assembling module is configured to find one or more target business subclasses and attribute information of each target business subclass that match the business type from a plurality of pre-set business subclasses, wherein each business subclass inherits a pre-set basic parent class, the business subclass declares a storage process and a retrieval process of attribute names and attribute values included in the attribute information, and assembles a business request based on the basic parent class, one or more target business subclasses, and attribute information of each target business subclass; The interaction module is configured to send the assembled business request to the server. The request assembling module is further configured to determine an assembling format of the service request according to a request type indicated by the request generation instruction, wherein the request type is a publishing type for actively sending a message to the server or a responding type for responding to the server; obtain service logic and one or more first attribute names of a request message body belonging to the request type from the second service sub-class corresponding to the request message body included in the base parent class and one or more second service sub-classes included in the target service sub-classes; obtain attribute values of the one or more first attribute names from attribute information of the second service sub-classes included in the attribute information of the target service sub-classes; assemble the service logic and the one or more first attribute names and the attribute values in the form of key-value pairs to obtain a message body satisfying the assembling format; and assemble the message body and a message header determined by the request generation instruction to obtain the service request.

13. An electronic device, comprising: comprising: one or more processors; a memory device for storing one or more programs, when the one or more programs are executed by the one or more processors, the one or more processors implement the method according to any one of claims 1-11.

14. A computer readable medium having stored thereon a computer program, characterized in that, The program is executed by the processor to implement the method according to any one of claims 1-11.

15. A computer program product comprising a computer program, characterized in that, The computer program is executed by the processor to implement the method according to any one of claims 1-11.

Images