Business processing methods and related equipment

Abstract

This application discloses a business processing method and related equipment. The method includes: manipulating the interface protocol layer to verify the request information carried in the interface call request according to preset interface protocol information, and sending the successfully verified request information to the target interface; triggering the target interface to run the target business logic based on the request information, and returning the running result of the target business logic to the target container through the communication layer, wherein the target business logic is configured according to the interface protocol information. Using preset interface protocol information as a reference for information verification and business logic configuration helps to uniformly constrain request information and interface business, reduce coding redundancy and complexity, and facilitate business integration and management of interface services. The interface protocol layer, communication layer, and target container are decoupled from each other, which can effectively improve the multi-terminal reuse capability and scalability of the interface, and improve the matching degree between the interface and the business.

Description

Technical Field

[0001] This application relates to the field of Internet technology, and in particular to business processing methods and related equipment. Background Technology

[0002] In practice, API calls allow users to obtain corresponding processing services or functions without needing to access or understand the specific working details of the source code.

[0003] However, existing interface management solutions support a limited number of containers, generally only supporting Flutter communication interfaces. Therefore, their scalability and compatibility with interfaces on Web, Android, or iOS platforms are weak, often requiring custom coding for each business need. This results in significant resource consumption in interface development and business management during operation and maintenance. Therefore, it is necessary to provide an effective solution. Summary of the Invention

[0004] This application provides a business processing method and related equipment to reduce the coding and maintenance costs of interfaces.

[0005] The first aspect of this application provides a business processing method, including:

[0006] Use the communication layer to forward the target container's interface call requests;

[0007] The control interface protocol layer verifies the request information carried in the interface call request according to the preset interface protocol information, and sends the successfully verified request information to the target interface. The interface protocol layer, the communication layer and the target container are decoupled from each other.

[0008] The target interface is triggered to run the target business logic based on the request information, and the running result of the target business logic is returned to the target container through the communication layer. The target business logic is configured according to the interface protocol information.

[0009] A second aspect of this application provides an electronic device, including:

[0010] Central processing unit, memory, and input / output interfaces;

[0011] The memory is either a short-term storage memory or a persistent storage memory;

[0012] The central processing unit is configured to communicate with the memory and execute instructions in the memory to perform the method described in the first aspect of the embodiments of this application or any specific implementation thereof.

[0013] A third aspect of this application provides a computer-readable storage medium including instructions that, when executed on a computer, cause the computer to perform the method described in the first aspect of this application or any specific implementation thereof.

[0014] A fourth aspect of this application provides a computer program product comprising instructions or a computer program, which, when run on a computer, causes the computer to perform the method described in the first aspect of this application or any specific implementation thereof.

[0015] As can be seen from the above technical solutions, the embodiments of this application have at least the following advantages:

[0016] Using pre-defined interface protocol information as a reference for information verification and business logic configuration helps to unify and standardize request information and interface business, reducing coding redundancy and complexity, thereby facilitating business integration and management of interface services. On the other hand, the decoupling relationship between the interface protocol layer, communication layer, and target container can effectively improve the multi-terminal reuse capability and scalability of the interface, facilitate service differentiation and maintenance, and avoid affecting the matching degree between the interface and business requirements. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments recorded in this application. For those skilled in the art, other drawings can be obtained based on these drawings.

[0018] Figure 1 This is a flowchart illustrating a business processing method according to an embodiment of this application;

[0019] Figure 2 This is another flowchart illustrating the business processing method of an embodiment of this application;

[0020] Figure 3 This is another flowchart illustrating the business processing method of an embodiment of this application;

[0021] Figure 4 This is another flowchart illustrating the business processing method of an embodiment of this application;

[0022] Figure 5 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0023] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0024] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification, claims, and drawings of this application are used to distinguish similar objects and are not necessarily used to describe a particular order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0025] In the following description, expressions such as "one specific implementation" or "one specific example" are used, which describe a subset of all possible embodiments. However, it is understood that "one specific implementation" or "one specific example" can be the same subset or a different subset of all possible embodiments, and can be combined with each other without conflict. In the following description, the term "plural" means at least two. The statement that a certain value reaches a threshold (if it exists) as used in this application may, in some specific examples, include cases where the former is greater than the latter.

[0026] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0027] For ease of understanding and explanation, before providing a further detailed description of this application, the nouns and terms involved in the embodiments of this application will be explained, and the nouns and terms involved in the embodiments of this application shall be interpreted as follows.

[0028] SDK: short for Software Development Kit, is a collection of documents, examples and tools that help develop a certain type of software.

[0029] A web container is a service program that provides corresponding services on a single port of a server and can handle requests from clients.

[0030] Flutter is an open-source toolkit from Google for building user interfaces (UI).

[0031] NPM: short for NodePackageManager, is a package management and distribution tool that comes with NodeJS. It makes it easy for JavaScript developers to download, install, upload, and manage installed packages.

[0032] The method described in this application will be further explained in detail below.

[0033] Please see Figure 1 The first aspect of this application provides a specific embodiment of a business processing method, which includes the following operation steps:

[0034] 11. Use the communication layer to forward the target container's interface call requests.

[0035] The target container can be any of HTML5 (H5), Hippy, WebView, and Flutter containers. After receiving the interface call request from the target container, the communication layer can forward the interface call request, such as forwarding it to the interface protocol layer for information verification and information distribution.

[0036] 12. The control interface protocol layer verifies the request information carried in the interface call request according to the preset interface protocol information, and sends the successfully verified request information to the target interface.

[0037] To effectively improve the security and accuracy of method or information invocation processes, an interface protocol layer can be used to verify the request information carried in the interface call request based on preset interface protocol information, and the successfully verified request information can be sent to the target interface. The interface protocol layer, communication layer, and target container are decoupled from each other. The advantages of this setup are that it avoids the original interface call process, where the communication layer and interface protocol layer are coupled together (which can be considered as the communication layer being coupled with business logic), making it difficult to distinguish and maintain different interface services, and making it inconvenient to add the aforementioned verification logic, thus affecting the call process.

[0038] 13. Trigger the target interface to run the target business logic based on the request information, and return the running result of the target business logic to the target container through the communication layer.

[0039] The target business logic can be configured based on the interface protocol information, which allows each interface to meet the unified protocol configuration requirements, thus facilitating scheduling and standardized management.

[0040] In summary, the embodiments of this application use preset interface protocol information as a reference for information verification and business logic configuration, which helps to unify and standardize request information and interface business, reduce coding redundancy and complexity, and thus facilitate business integration and management of interface services. On the other hand, the interface protocol layer, communication layer, and target container are decoupled from each other, which can effectively improve the multi-terminal reuse capability and scalability of the interface, facilitate service differentiation and maintenance, and avoid affecting the matching degree between the interface and business requirements.

[0041] Based on the examples above, some specific possible implementation examples will be provided below. In practical applications, the implementation details of these examples can be combined as needed according to the corresponding functional principles and application logic.

[0042] Please see Figures 2 to 4 This application provides another specific embodiment of a business processing method, which includes the following operation steps:

[0043] 20. Build a suitable communication layer for each container.

[0044] The communication layers are decoupled from each other, and the target container can be any one of the containers. For example... Figure 3 As shown, for containers such as H5, Hippy, WebView, and Flutter, their respective adaptive communication layers (or Bridge layers) are built: webbridge, HippyBridge, JsBridge, and methodChannel, establishing a one-to-one correspondence between containers and channels. Considering that coupled structures can easily increase coding workload and cause compatibility issues across platforms, the communication layers can be decoupled to improve the applicability and response efficiency of the interface to various containers and facilitate information retrieval.

[0045] 21. Use the communication layer to forward the target container's interface call requests.

[0046] Specifically, when different containers are used as target containers, their respective corresponding Bridge channel layers can be used to forward interface call requests and other information. For example, when the Hippy container is the target container, its HippyBridge can be used to forward interface call requests to avoid delays in information transmission due to compatibility issues.

[0047] 22. The control interface protocol layer verifies the request information carried in the interface call request according to the preset interface protocol information, and sends the successfully verified request information to the target interface.

[0048] In some specific implementation examples, the interface protocol information may include the field names and field types agreed upon for the request information. In practical applications, the request information may exist in the form of a request body. Accordingly, the specific operation process of "manipulating the interface protocol layer to verify the request information carried by the interface call request according to the preset interface protocol information" in step 22 may include:

[0049] The control interface protocol layer verifies whether the field names and field types in the request information correspond to the pre-agreed field names and field types, and determines the request information with the verification result as the request information to be sent to the target interface.

[0050] Specifically, the format of field names and types in the request information (which can be in the form of a request body) can be pre-defined. The field names and types sent by the target container should conform to the aforementioned format requirements. For example, the method name "Action" returned by the request should be standardized as "abc" and in a standard text format. This effectively authenticates or verifies information from the target container, ensuring information security. In addition to defining or declaring the names and types of the request fields (or interface parameters), a unified return code can also be defined, such as code=1 indicating success and code=0 indicating failure. Alternatively, a response format can also be agreed upon.

[0051] In some specific implementation examples, the process of presetting the above interface protocol information may include the following operations:

[0052] Use the communication protocol to declare the field names and types of at least one of the following: request body, response body, action method, and callback function; compile the declared field names and types into a preset code template to generate interface protocol information adapted to different operating system containers.

[0053] The aforementioned communication protocol can be TypeScript (or simply Ts protocol) or protobuf protocol, etc. Generally, using the Ts protocol is more front-end friendly and convenient for operation and maintenance. Figure 4As shown, the field names and types of the aforementioned Request and other agreed-upon information can be declared through the TypeScript protocol. Then, a compiler can be used to perform compilation checks on this declared information. This compilation check can refer to or be based on a preset code template, thereby effectively generating source code files (i.e., source files) adapted to operating systems such as web, Android, or iOS. These source files can record interface protocol information. Furthermore, the source files can be versioned and updated using library management tools such as Npm, Maven, and Pods for use on operating systems like web, Android, or iOS, thus enabling updates or iterations of the interface and its business logic. Based on the above explanation, the source code files can be understood as being used to build the SDK, specifically to build the interface protocol layer.

[0054] The Action classes described above serve as a bridge between user requests and business logic; each Action can act as a proxy for a client's business request. Of course, in specific instances, other predefined conventions besides Request can be established for the interface protocol layer. These could include a dispatcher for tasks such as data reading or validation, an interface protocol or network data exchange rule, a plugin or computer application, a proxy server, and an exception handler for handling errors—generally applicable processing logic.

[0055] like Figure 3 As shown, the web-side container layer, communication layer, and interface protocol layer can be considered as building an interface (standardized) SDK. This SDK can be built using the TypeScript protocol and is compatible with interfaces from Web, Android, and iOS systems. The Request layer within the SDK performs field name and type validation on the data in the request information. The Callback layer within the SDK performs field name and type validation on the data returned to the callback from the client (e.g., WebView). Successfully validated request information (referred to as request parameters) can be distributed to the target interface. Specifically, this can be seen as distribution to the business module on the interface connection side for specific business logic processing and result return. These business modules can be different modules within a specific app within the app's business layer, such as network, user information caching, and container modules within a song playback or karaoke app.

[0056] In some specific implementation examples, the process of configuring the target business logic based on the interface protocol information described above may include the following operations:

[0057] Based on the field names and field types specified in the interface protocol information, configure at least one business logic including opening a webpage and / or activating a user operation panel, wherein the business logic that corresponds to the request information is the target business logic.

[0058] Specifically, the business-side processing logic, or business logic, can be at least one of the following: opening a webpage, activating a user control panel, or returning user information to the web client. The specific configuration can be tailored to the actual situation. For example, if the target container requests certain user information under the name APP-A, and this request is successfully verified by the interface protocol layer, the corresponding target interface can be triggered to find and execute its target business logic. The function implemented by this target business logic includes calling the specified user information under APP-A to the target container.

[0059] 23. Trigger the target interface to run the target business logic based on the request information, and return the running result of the target business logic to the target container through the communication layer.

[0060] Based on the above explanation, it can be seen that the corresponding business module can be found through the target interface, and then the corresponding target business logic can be found and run in a related manner, thereby successfully realizing the information retrieval. In some specific examples, the interface protocol information may include the field names and field types agreed upon for the return body (Response) or callback function. Accordingly, the specific operation of step 23, "returning the running result of the target business logic to the target container through the communication layer," may include:

[0061] The system verifies whether the field content of the execution result conforms to the field names and types declared in the return body or callback function. If it does not conform (one reason being incorrect field naming or type format in the execution result), then one possible implementation method is executed: at least an error message serving as the execution result is sent to the target container, and the field content is modified according to the field names and types agreed upon in the return body or callback function. This is equivalent to handling the error logic at the result level. If it conforms, the field content is returned to the target container through the communication layer. This error message can be understood as notifying the target container of the execution result of the aforementioned target business logic. Of course, if the above verification fails, an error message can also be sent to structures other than the target container, such as plugins or proxy servers in the interface protocol layer, to prompt for error handling as described in the second implementation method below.

[0062] The aforementioned validation of field names and types in the execution results of the target business logic helps control the accuracy and standardization of the returned results, improving information response security. This validation of the execution results can be considered as primarily performed by the interface protocol layer. Specifically, if the validation result is invalid, a failure return code (code=0) can be sent to the target container; otherwise, a success return code (code=1) can be sent to the target container as a notification.

[0063] The above execution results may be invalid for reasons such as incorrect configuration of the original target business logic, such as a lack of prior agreement on some field names and / or field types. Therefore, the corresponding possible instance operations are as follows: If the validation conclusion of the field content in the execution result is invalid, such as the execution result indicating the presence of additional field content that was not agreed upon beforehand, then the following possible implementation method two can be executed:

[0064] Based on the error messages and request information obtained from the verification, the field names and types specified in the interface protocol information are modified (including supplementing field names and redefining field types) to configure a new target business logic. This new target business logic replaces the original target business logic and outputs new results. This is equivalent to handling the error logic at the dependency or cause level. This ensures that the field content in the result of the new target business logic can be verified one-to-one with the modified field names and types in the interface protocol information, guaranteeing that each field in the result has a comparable reference standard. In other words, if the specific business implementation logic of the interface needs to be modified, its dependent resources (such as the source files described later) can be modified accordingly. For example, modifying the field names and types pre-deployed according to the TS protocol can configure a new target business logic.

[0065] In conclusion, Figure 3 The channel layer in the SDK layer shown is a communication channel Bridge adapted to different containers, mainly responsible for forwarding information. The interface protocol layer is mainly responsible for defining and validating the content of fields (or parameters), and can also distribute information. The APP business layer is used to cooperate with the interface to implement business logic, thereby completing the call to information.

[0066] In summary, this application's embodiments, by decoupling the communication layer and the interface protocol layer, enable the interface to scalably support access from multiple web containers such as Hippy, WebView, and Flutter. This breaks the barrier of existing solutions that only support Flutter containers, enhances the multi-terminal reusability and coding quality of the interface, thereby improving R&D efficiency and resource utilization. It allows for the reuse of the same TypeScript interface protocol, and data format constraints and standardization can be achieved through built-in unified return codes and response structures, ensuring consistency and accuracy during information verification and distribution. Furthermore, interfaces can be managed or packaged as functions at the project level. For example, interfaces corresponding to game projects or those associated with the same business app can be managed by dividing them into modules or repositories, making the business logic corresponding to the interfaces more aligned with actual business needs. This provides broader basic capability support for the rapid deployment of different businesses on multiple platforms.

[0067] The operations of steps 21 to 23 above are similar to those of steps 11 to 13, and will not be repeated here.

[0068] Please see Figure 5 The electronic device 500 of the second aspect of the present application embodiment may include one or more central processing units (CPUs) 501 and a memory 505, wherein the memory 505 stores one or more applications or data.

[0069] The memory 505 can be volatile or persistent storage. The program stored in the memory 505 can include one or more modules, each module including a series of instruction operations on the electronic device. Furthermore, the central processing unit 501 can be configured to communicate with the memory 505 and execute the series of instruction operations stored in the memory 505 on the electronic device 500.

[0070] Electronic device 500 may also include one or more power supplies 502, one or more wired or wireless network interfaces 503, one or more input / output interfaces 504, and / or one or more operating systems, such as Windows Server™, MacOSX™, Unix™, Linux™, FreeBSD™, etc.

[0071] The central processing unit 501 can perform the operations performed by the first aspect or any specific method embodiment of the first aspect, which will not be described in detail here.

[0072] This application provides a computer-readable storage medium including instructions that, when executed on a computer, cause the computer to perform the method as described in the first aspect or any specific implementation thereof.

[0073] This application provides a computer program product containing instructions or computer programs, which, when run on a computer, causes the computer to perform the method described in the first aspect or any specific implementation thereof.

[0074] It is understood that, in the various embodiments of this application, the sequence number of each step does not imply the order of execution. The execution order of each step should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0075] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the system (if it exists) and device described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0076] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system or apparatus, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

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

[0078] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0079] If the integrated unit is implemented as 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 technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product (computer program product) is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a business server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

Claims

1. A business processing method, characterized in that, include: Each container builds its own adapted communication layer, and the communication layers are decoupled from each other. The target container is any one of the containers. The target container's interface call requests are forwarded using the communication layer adapted to the target container. The control interface protocol layer verifies the request information carried in the interface call request according to the preset interface protocol information, and sends the successfully verified request information to the target interface. The interface protocol layer, the communication layer, and the target container are decoupled from each other. The interface protocol information is information that is generated by compiling the field names and field types declared in the communication protocol to adapt to different operating system containers. The target interface is triggered to run the target business logic based on the request information, and the running result of the target business logic is returned to the target container through the communication layer. The target business logic is configured according to the interface protocol information.

2. The business processing method according to claim 1, characterized in that, The interface protocol information includes the field names and field types agreed upon for the request information; The control interface protocol layer verifies the request information carried in the interface call request according to preset interface protocol information, including: The interface protocol layer is controlled to verify whether the field names and field types in the request information correspond to the pre-agreed field names and field types, and the request information with the verification result is determined as the request information to be sent to the target interface.

3. The business processing method according to claim 1, characterized in that, Before the control interface protocol layer verifies the request information carried in the interface call request according to the preset interface protocol information, the business processing method further includes: Use the communication protocol to declare the field names and field types of at least one of the agreed-upon information in the request body, return body, delegate method Action, and callback function; The declared field names and field types are compiled into a preset code template to generate interface protocol information that is compatible with different operating system containers.

4. The business processing method according to claim 3, characterized in that, The communication protocol includes Typescript or protobuf.

5. The business processing method according to claim 1, characterized in that, The process of configuring the target business logic according to the interface protocol information includes: Based on the field names and field types specified in the interface protocol information, configure at least one business logic including opening a webpage and / or activating a user operation panel, wherein the business logic that corresponds to the request information is the target business logic.

6. The business processing method according to claim 1, characterized in that, The interface protocol information includes the field names and field types agreed upon for the return body or callback function; The step of returning the execution result of the target business logic to the target container through the communication layer includes: Verify whether the field content in the execution result conforms to the field name and field type requirements declared in the return body or the callback function; If it does not meet the requirements, at least an error message that serves as the running result should be sent to the target container, and the field content should be modified according to the field name and field type agreed upon for the return body or the callback function. If the conditions are met, the field content is returned to the target container through the communication layer.

7. The business processing method according to claim 1, characterized in that, The step of returning the execution result of the target business logic to the target container through the communication layer includes: If the verification result of the field content in the running result is non-compliant, then based on the error message obtained from the verification and the request information, the field name and field type agreed in the interface protocol information are modified to configure a new target business logic. The new target business logic is used to replace the original target business logic to output a new running result.

8. An electronic device, characterized in that, include: Central processing unit, memory, and input / output interfaces; The memory is either a short-term storage memory or a persistent storage memory; The central processing unit is configured to communicate with the memory and execute instructions in the memory to perform the method according to any one of claims 1 to 7.

9. A computer-readable storage medium, characterized in that, Includes instructions that, when executed on a computer, cause the computer to perform the method as described in any one of claims 1 to 7.

10. A computer program product comprising instructions or a computer program, characterized in that, When the computer program product is run on a computer, it causes the computer to perform the method as described in any one of claims 1 to 7.

Images