A method and system for calling a WebAssembly plugin in an API request pipeline

Abstract

The present invention discloses a method and system for calling a WebAssembly plug-in in an API request pipeline, including: the caller initializes a WebAssembly instance and allocates a first memory for the WebAssembly instance; prepares an object with an input data structure and stores it in a second memory; calls a memory allocation function of WebAssembly to apply for a third memory; copies the serialized data of the object to the third memory of WebAssembly; calls an execution function to obtain and parse a return value; deserializes the return value into an object with an output data structure, and constructs an actual response value. The present invention loads a WebAssembly plug-in in the API request pipeline of a ToB software server, overcoming the deficiencies of existing customized solutions in terms of security, stability, and scalability.

Description

Technical Field

[0001] The present invention relates to the technical field of electronic digital data processing, in particular to the technical field of software engineering design, and specifically to a method and system for calling a WebAssembly plug-in in an API request pipeline. Background Art

[0002] The customization mechanism provided by ToB software includes customization of the front-end interactive interface and customization of the server-side logic; the front-end interactive interface customization is to inject tenant-customized scripts into the front-end interface to affect the front-end interactive behavior, or allow tenants to embed customized front-end components and pages; there are several ways to customize the server-side logic. One is to allow tenants to write new business APIs themselves and provide them to the front-end or external interface calls; the other is to use the AOP (Aspect Oriented Programming) mechanism to supplement the existing API logic without modifying the original logic. This method is called a plug-in or trigger.

[0003] With the continuous development of the ToB (To Business) software market, multi-tenant SaaS software architecture has become mainstream. This type of architecture allows software providers to use one instance of a set of software to provide services to multiple tenants, effectively reducing operation and maintenance costs and improving resource utilization. However, the differences in needs between different tenants have brought about customization needs, especially in the customization of server-side logic. At present, server-side logic customization is mainly achieved by providing high-level language SDKs, allowing source code to be uploaded to the server for compilation, or integrating script interpreters. Although these methods meet customization needs to a certain extent, they each have obvious defects, which limit the flexibility, security and performance of ToB software.

[0004] Therefore, it is necessary to improve the method and system for calling the WebAssembly plug-in in the API request pipeline in the prior art to solve the above problems. Summary of the invention

[0005] The present invention overcomes the deficiencies of the prior art and provides a method and system for calling a WebAssembly plug-in in an API request pipeline, aiming to solve the problems of insufficient security, stability and scalability of customized solutions in the prior art.

[0006] To achieve the above object, the technical solution adopted by the present invention is: a method for calling a WebAssembly plug-in in an API request pipeline, comprising:

[0007] S1. The caller initializes the WebAssembly instance, allocates a first memory for the WebAssembly instance, and records a first starting address of the first memory;

[0008] S2. Prepare an object with an input data structure, store serialized data of the object in a second memory, and record a second starting address and a size of the second memory;

[0009] S3. Call the memory allocation function of WebAssembly to apply for the third memory and return the memory address of the third memory.

[0010] S4. Copy the serialized data of the object to the third memory of WebAssembly.

[0011] S5. Call the execution function, obtain and parse the return value;

[0012] S6. Deserialize the return value into an object with an output data structure, and construct an actual response value based on the object with the output data structure.

[0013] In a preferred embodiment of the present invention, in step S2, the serialization method is one of json, protobuf and xml; when json and xml are used to serialize an object with an input data structure, the serialization result is converted into UTF-8 encoded binary content.

[0014] In a preferred embodiment of the present invention, in step S3, the memory allocation function is used by the caller to apply for memory from WebAssembly, the input parameter is the memory length to be applied for, and the return value is the applied memory address; the applied memory address is a relative address in the memory block that WebAssembly has permission to access.

[0015] In a preferred embodiment of the present invention, in step S3, the size of the third memory is consistent with the size of the second memory.

[0016] In a preferred embodiment of the present invention, the execution function is a function in WebAssembly used to process business logic; the first parameter and the second parameter of the execution function jointly define an input memory block; wherein the first parameter is the memory address of the incoming data, the first parameter comes from the return value of calling the memory allocation function, and the second parameter is the memory length occupied by the incoming data.

[0017] In a preferred embodiment of the present invention, in step S5, the first parameter of the execution function input is the third memory address, and the second parameter is the size of the third memory;

[0018] WebAssembly deserializes the input data passed by the caller based on the first and second parameters inside the execution function;

[0019] Before executing the function return, WebAssembly prepares an object with the output data structure and serializes it into the WebAssembly memory.

[0020] In a preferred embodiment of the present invention, a WebAssembly exports multiple functions for processing business logic, the function names are different, and the parameter types, number of parameters and return value types are the same.

[0021] The present invention provides a system for calling a WebAssembly plug-in in an API request pipeline, comprising: a WebAssembly storage module, a plug-in definition storage module, a plug-in matching module, and a plug-in execution module;

[0022] WebAssembly storage module, which is used to store WebAssembly file contents, assign a unique ID to each WebAssembly file, and store WebAssembly binary contents;

[0023] The plugin definition storage module is used to store the definition of WebAssembly plugins;

[0024] The plug-in matching module is used to extract the context information required for plug-in operation from the API request information, including: current user information, routing key information, request method, request header, request body; assemble into the context required for matching; load all plug-in definitions from the plug-in storage module and the corresponding cache, bring the context information into the matching rules of each plug-in for calculation, find out all valid plug-ins that match this request, and group them by the execution position of the plug-in, sort them by the execution sequence number in the same group, call the plug-in execution module in sequence at the specified execution position, and execute the plug-ins one by one;

[0025] The plugin execution module finds the WebAssembly ID from the plugin definition module, finds the corresponding WebAssembly in the WebAssembly storage, loads the WebAssembly binary code, instantiates the WebAssembly, and calls the method executed in the WebAssembly specified in the plugin definition.

[0026] In a preferred embodiment of the present invention, the plug-in definition includes:

[0027] The plug-in matching rule module is used to determine whether a specific API request needs to call this plug-in;

[0028] The plugin call location module is used to indicate whether the plugin is called before or after the API action is executed;

[0029] The sorting module called by the plug-in. When the same API request needs to call multiple plug-ins at the same location, they are called in sorted order;

[0030] WebAssembly ID module: finds the corresponding WebAssembly binary content in the WebAssembly storage through the WebAssembly ID;

[0031] WebAssembly function name module: When a WebAssembly contains multiple callable methods, define multiple plugins to reuse WebAssembly and reduce the number of WebAssembly

[0032] The present invention solves the defects existing in the background technology and has the following beneficial effects:

[0033] (1) The present invention loads a WebAssembly plug-in in the API request pipeline of the ToB software server to overcome the deficiencies of existing customized solutions in terms of security, stability and scalability. Through the sandbox isolation feature and near-native execution speed provided by WebAssembly, the context of code execution is effectively limited to prevent malicious or erroneous code from affecting system stability, while improving performance and scalability.

[0034] (2) The present invention combines the sandbox isolation mechanism of WebAssembly with the method of calling WebAssembly to ensure that the WebAssembly plug-in is executed in a restricted environment, thereby avoiding security issues caused by tenant code. The memory management and execution control mechanism of WebAssembly ensures that even malicious or erroneous code cannot affect the core part of the system, thereby achieving higher security protection. Compared with the existing technology, it further achieves the effect of preventing unauthorized access to code and abuse of resources.

[0035] (3) The present invention allocates an independent memory space for WebAssembly and records the starting address. This step, combined with the binary execution characteristics of WebAssembly, ensures that the WebAssembly code runs in an independent sandbox environment, thereby improving the security of the system; through the combination of step S3 and step S4, the management of WebAssembly memory and the transfer of data are realized; in step S3, the caller applies for the third memory through the memory allocation function of WebAssembly, and step S4 copies the serialized data to the third memory of WebAssembly; this combination effectively limits the context of code execution, prevents malicious or erroneous code from affecting the overall stability of the system, realizes the safe management of resources and accurate transfer of data, and further achieves the effect of enhancing system security compared with the prior art.

[0036] (4) The present invention realizes dynamic processing of API requests by combining a plug-in matching module and a plug-in execution module. The plug-in matching module extracts context information based on the API request information and matches the corresponding plug-in, while the plug-in execution module is responsible for loading WebAssembly and executing the specified method. This combination enables API requests to dynamically call different plug-ins based on different context information, realizing flexible processing of API requests. Compared with the prior art, it further achieves the effect of improving system adaptability and personalized service capabilities.

[0037] (5) The design of the WebAssembly storage module and the plug-in definition storage module in the second embodiment of the present invention allows new WebAssembly plug-ins to be easily added, and the behavior of the plug-in can be changed by adjusting the plug-in definition without changing the core code, thereby enhancing the flexibility and scalability of the system and being able to adapt to changes in business needs more quickly than traditional methods. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art are briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in the present invention. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative work.

[0039] Figure 1 is a method flow chart of a preferred embodiment of the present invention;

[0040] Figure 2 It is a system structure diagram of a preferred embodiment of the present invention. DETAILED DESCRIPTION

[0041] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0042] In the following description, many specific details are set forth to facilitate a full understanding of the present invention, but the present invention may also be implemented in other ways different from those described herein. Therefore, the protection scope of the present invention is not limited to the specific embodiments disclosed below.

[0043] Application Overview:

[0044] There are several ways that ToB software customizes server-side logic, all of which have certain defects: 1. Based on the high-level language SDK, in a multi-tenant environment, it is impossible to completely restrict the tenant's customized code's access to server resources, and there is a risk of unauthorized access; a single tenant's customized code exception may cause the entire service to crash, affecting the stability of the service; there are specific requirements for the development language, which limits the flexibility of system expansion; 2. The method of uploading source code to the server for compilation, although the tenant code can be security checked and analyzed, there are still risks such as causing dead loops and exhausting server resources; 3. The method of integrating script interpreters, the performance of scripts is significantly different from that of native codes, which may cause performance bottlenecks and cannot meet the needs of computing-intensive businesses; different tenants may use different technology stacks, and the server needs to integrate multiple script engines, which increases the complexity of integration; some scripts rely on specific back-end technologies, which limits their use in different environments. In summary, the existing technology has many defects in server-side logic customization and cannot meet the needs of ToB software in terms of security, stability and scalability.

[0045] WebAssembly is a binary format that can run in modern browsers. It provides near-native execution speed and has good sandbox isolation features, which can effectively limit the context of code execution and prevent malicious or erroneous code from affecting the overall stability of the system. Therefore, this application aims to overcome the problems of insufficient security, stability and scalability of existing customized solutions by loading WebAssembly plug-ins in the API request pipeline of the ToB software server.

[0046] Exemplary Methods

[0047] like Figure 1 As shown, a method for calling a WebAssembly plug-in in an API request pipeline includes the following steps:

[0048] S1. The caller initializes the WebAssembly instance, allocates a first memory for the WebAssembly instance, and records a first starting address of the first memory;

[0049] S2. Prepare an object with an input data structure, store serialized data of the object in a second memory, and record a second starting address and a size of the second memory;

[0050] S3. Call the memory allocation function of WebAssembly to apply for the third memory and return the memory address of the third memory.

[0051] S4. Copy the serialized data of the object to the third memory of WebAssembly.

[0052] S5. Call the execution function, obtain and parse the return value;

[0053] S6. Deserialize the return value into an object with an output data structure, and construct an actual response value according to the object with the output data structure;

[0054] WebAssembly is an open standard binary instruction set. The memory during the WebAssembly execution process is managed by the WebAssembly code, and the caller is not responsible for the memory management of the WebAssembly during operation. The WebAssembly module is responsible for allocating and releasing memory, and the external caller only needs to know how to request memory and receive the results.

[0055] In step S1, initializing the WebAssembly instance refers to the process of creating an executable environment for WebAssembly before calling the WebAssembly plug-in;

[0056] Specifically, in step S1, the first starting address recorded is @start; the first memory is used for all memory operations of WebAssembly;

[0057] The caller serializes the object with the input data structure into a memory block before calling the WebAssembly function, passing the memory block information as the final parameter.

[0058] In step S2, the second starting address is recorded as @ptr1; the second memory size is recorded as @size;

[0059] In step S2, the serialization method is one of json, protobuf and xml; when json and xml are used to serialize an object having an input data structure, the serialization result is converted into binary content encoded in UTF-8.

[0060] JSON is a lightweight data exchange format that is easy to read and write, and also easy for machines to parse and generate; Protobuf is an efficient protocol message encoding and decoding solution that provides a more compact binary format than JSON and is suitable for situations where efficient data transmission or storage is required; XML is a markup language used to store and transmit data.

[0061] In step S3, in order to allow the caller to request memory, the WebAssembly module exports a memory allocation function; specifically, the signature of the memory allocation function is i32 _malloc(i32); i32 represents a 32-bit integer, which means that this function accepts a 32-bit integer parameter representing the requested memory length and returns a 32-bit integer representing the address of the allocated memory.

[0062] The name of the memory allocation function is not necessarily _malloc, but the function signature must be the same. The function name of the memory allocation function is defined in the WebAssembly storage. In this application, _malloc is used as an example for detailed explanation;

[0063] In step S3, the memory allocation function is used by the caller to request memory from WebAssembly. The input parameter is the length of the memory to be requested, and the return value is the requested memory address. The requested memory address is a relative address in the memory block that WebAssembly has access to.

[0064] In step S3, the size of the third memory is consistent with the size of the second memory, the size of the third memory is recorded as @size, and the third memory address returned by the memory allocation function is recorded as @ptr2;

[0065] In step S4, the starting address of the third memory is @start + @ptr2; the caller copies the serialized object data with the starting address of the memory being @ptr1 and the memory size being @size to the third memory;

[0066] The execution function is a function used to process business logic in WebAssembly. Specifically, the signature is i64execute(i32, i32), where execute is the function name and is replaced according to the actual situation, but the number and type of input parameters and return values ​​remain unchanged. The first parameter and the second parameter together define an input memory block. The first parameter is the memory address of the incoming data, which comes from the return value of calling the memory allocation function, and the second parameter is the memory length occupied by the incoming data.

[0067] The return value is a composite value representing a memory block in WebAssembly memory. The upper 32 bits are the starting address of the returned content in WebAssembly memory, and the lower 32 bits are the byte length of the returned content.

[0068] Before returning, WebAssembly constructs a memory block with an output data structure and uses the information of this memory block as the return value; the caller deserializes the content in the memory block into an object with an output data structure based on the returned memory block information.

[0069] In step S5, the first parameter of the execution function input is the third memory address @ptr2, and the second parameter is the size of the third memory @size;

[0070] WebAssembly deserializes the input data passed by the caller based on these two parameters inside the execution function;

[0071] Before executing the function return, WebAssembly prepares an object with the output data structure and serializes it into the WebAssembly memory. The starting address of the WebAssembly memory is @ptr3, and the size is @size3. The return value is (((i64)@ptr3)<<32) + @size3.

[0072] In step S5, after the execution of the execute function is completed, the caller obtains the return value, which is recorded as @return; the return value is parsed to obtain the memory address @ptr4 and the length @size4;

[0073] The parsing rules are:

[0074] @ptr4 = (@return>>32)&0xFFFFFFFF,

[0075] @size4 = @return& 0xFFFFFFFF;

[0076] In step S5, the memory address of the output data is recorded as @start + @ptr4; the memory size is @size4; @start is the starting address of the memory allocated by the caller for WebAssembly.

[0077] In step S5, the same WebAssembly can export multiple functions for processing business logic. The function signature is similar to the execute function, with only the function name being different. The parameter type, number of parameters, and return value type are the same.

[0078] Exemplary Systems

[0079] like Figure 2 As shown, a system for calling a WebAssembly plug-in in an API request pipeline includes: a WebAssembly storage module, a plug-in definition storage module, a plug-in matching module, and a plug-in execution module;

[0080] WebAssembly storage module, which is used to store WebAssembly file contents, assign a unique ID to each WebAssembly file, and store WebAssembly binary contents;

[0081] The plugin definition storage module is used to store the definition of WebAssembly plugins;

[0082] The plug-in matching module is used to extract the context information required for plug-in operation from the API request information, including: current user information, routing key information, request method, request header, request body; and assemble it into the context required for matching. All plug-in definitions are loaded from the plug-in storage or the corresponding cache, and the context information is brought into the matching rules of each plug-in for calculation, and all valid plug-ins that match this request are found, and grouped by the execution position of the plug-in, and sorted by the execution sequence number in the same group. At the specified execution position, the plug-in execution module is called in sequence, and the plug-ins are executed one by one;

[0083] The plugin execution module finds the WebAssembly ID from the plugin definition, finds the corresponding WebAssembly in the WebAssembly storage, loads the WebAssembly binary code, instantiates the WebAssembly, and calls the method executed in the WebAssembly specified in the plugin definition.

[0084] The plugin definition contains:

[0085] The plug-in matching rule module is used to determine whether a specific API request needs to call this plug-in;

[0086] The plugin call location module is used to indicate whether the plugin is called before or after the API action is executed;

[0087] The sorting module called by the plug-in. When the same API request needs to call multiple plug-ins at the same location, they are called in sorted order;

[0088] WebAssembly ID module: finds the corresponding WebAssembly binary content in the WebAssembly storage through the WebAssembly ID;

[0089] WebAssembly function name module: When a WebAssembly contains multiple callable methods, define multiple plug-ins to reuse the WebAssembly and reduce the number of WebAssembly; Specific embodiments

[0090] This example is a server developed by Asp.Net Core. Only a default memory block is allocated for WebAssembly. The memory mentioned below refers to this default memory block, and it is assumed that the allocated memory size will not exceed Size in bytes;

[0091] The WebAssembly storage module uses a database to store WebAssembly. The table structure is defined as shown in the following table:

[0092] Table 1 WebAssembly storage module fields

[0093]

[0094] The plug-in definition storage module uses the database to store plug-in definitions. The storage table structure is defined as shown in the following table. The table name is PluginDefinitions. In this example, only RouteKey, HttpMethod and ExecutePosition are used to define matching rules.

[0095] Table 2 Plugin definition storage module fields

[0096]

[0097] The plugin matching module is implemented in the form of an API filter. Define a class WebAssemblyPluginFilter to implement the IActionFilter interface. The IActionFilter interface defines the OnActionExecuting and OnActionExecuted methods, which represent additional processing before and after the API action is executed.

[0098] The HTTP request URL address is a fixed prefix + dynamic part. After receiving the client request, the matching module obtains the dynamic part of the URL in the request, recorded as RouteKey, and obtains the request method (HttpMethod) in the request header, recorded as HttpMethod; and builds a plug-in matching context based on this information. The context is used to organize all the information required by the matching plug-in.

[0099] The plug-in matching module matches valid plug-ins from the plug-in storage module according to the matching context; the matching rules in this example only use RouteKey, HttpMethod and ExecutePosition; these three parameters can be used to represent specific events such as "before an entity is created" and "after an entity is updated";

[0100] Before the API action is executed, that is, in the OnActionExecuting method, the plugin matching module searches for plugin definitions with RouteKey=@RouteKey, HttpMethod=@HttpMethod and ExecutePosition=@PreAction in the plugin definition table (PluginDefinitions), and executes them in the order indicated by ExecuteOrder.

[0101] After the API action is executed, that is, in the OnActionExecuted method, the plug-in matching module searches the plug-in definition table (PluginDefinitions) for the plug-in definition with RouteKey=@RouteKey, HttpMethod=@HttpMethod and ExecutePosition=@PostAction, and executes them in the order indicated by ExecuteOrder.

[0102] The main body of the plug-in matching module is a class that implements the IActionFilter interface, and implements the OnActionExecuting and OnActionExecuted methods of the IActionFilter interface, which represent additional processing before and after the API action is executed, respectively.

[0103] The plug-in matching module runs in two locations: before and after the API action is executed. After matching the plug-in, the plug-in matching module calls the plug-in execution module to execute the corresponding plug-in and performs further processing based on the output data returned by the plug-in.

[0104] The plug-in execution module is used to execute specific plug-ins and is called by the plug-in matching module. Before executing the plug-in, the input data structure and output data structure between WebAssembly are first clarified.

[0105] Before calling WebAssembly, the plugin execution module needs to prepare input data according to the plugin definition, including RouteKey, HttpMethod, and if UseHttpHeaders=true is defined in the plugin definition, headers are passed in. If UseBody=true is defined in the plugin definition, body information in the http request is passed in.

[0106] In this example, the binary content of WebAssembly is taken out from the plug-in definition, the running restrictions of WebAssembly are configured, and an instance is built. Then, referring to the method of calling a WebAssembly plug-in in an API request pipeline mentioned in Example 1, the input data is serialized and passed into the memory of WebAssembly, and then the execution method of WebAssembly is called, and the return result of the execution method is deserialized into output data.

[0107] The above is based on the ideal embodiment of the present invention. Through the above description, relevant personnel can make various changes and modifications without departing from the technical concept of the present invention. The technical scope of the present invention is not limited to the content in the specification, and the technical scope must be determined according to the scope of the claims.

Claims

1. A method for calling a WebAssembly plug-in in an API request pipeline, characterized in that: Includes steps: S1. The caller initializes the WebAssembly instance, allocates a first memory for the WebAssembly instance, and records a first starting address of the first memory; S2. Prepare an object with an input data structure, store serialized data of the object in a second memory, and record a second starting address and a size of the second memory; S3. Call the memory allocation function of WebAssembly to apply for the third memory and return the memory address of the third memory. S4. Copy the serialized data of the object to the third memory of WebAssembly. S5. Call the execution function, obtain and parse the return value; S6. Deserialize the return value into an object with an output data structure, and construct an actual response value based on the object with the output data structure.

2. A method for calling a WebAssembly plug-in in an API request pipeline according to claim 1, characterized in that: In step S2, the serialization method is one of json, protobuf and xml; when json and xml are used to serialize an object having an input data structure, the serialization result is converted into binary content encoded in UTF-8.

3. A method for calling a WebAssembly plug-in in an API request pipeline according to claim 1, characterized in that: In step S3, the memory allocation function is used by the caller to request memory from WebAssembly. The input parameter is the length of the memory to be requested, and the return value is the requested memory address. The requested memory address is a relative address in the memory block that WebAssembly has permission to access.

4. A method for calling a WebAssembly plug-in in an API request pipeline according to claim 1, characterized in that: In step S3, the size of the third memory is consistent with the size of the second memory.

5. A method for calling a WebAssembly plug-in in an API request pipeline according to claim 1, characterized in that: The execution function is a function used to process business logic in WebAssembly. The first parameter and the second parameter of the execution function together define an input memory block. The first parameter is the memory address of the incoming data, which comes from the return value of calling the memory allocation function, and the second parameter is the memory length occupied by the incoming data.

6. A method for calling a WebAssembly plug-in in an API request pipeline according to claim 1, characterized in that: In step S5, the first parameter of the execution function input is the third memory address, and the second parameter is the size of the third memory; WebAssembly deserializes the input data passed by the caller based on the first and second parameters inside the execution function; Before executing the function return, WebAssembly prepares an object with the output data structure and serializes it into the WebAssembly memory.

7. A method for calling a WebAssembly plug-in in an API request pipeline according to claim 1, characterized in that: A WebAssembly exports multiple functions for processing business logic. The function names are different, but the parameter types, number of parameters, and return value types are the same.

8. A system for calling a WebAssembly plug-in in an API request pipeline, based on a method for calling a WebAssembly plug-in in an API request pipeline according to any one of claims 1 to 7, characterized in that: include: WebAssembly storage module, plugin definition storage module, plugin matching module, plugin execution module; WebAssembly storage module, which is used to store WebAssembly file contents, assign a unique ID to each WebAssembly file, and store WebAssembly binary contents; The plugin definition storage module is used to store the definition of WebAssembly plugins; The plug-in matching module is used to extract the context information required for plug-in operation from the API request information, including: current user information, routing key information, request method, request header, request body; assemble into the context required for matching; load all plug-in definitions from the plug-in storage module and the corresponding cache, bring the context information into the matching rules of each plug-in for calculation, find out all valid plug-ins that match this request, and group them by the execution position of the plug-in, sort them by the execution sequence number in the same group, call the plug-in execution module in sequence at the specified execution position, and execute the plug-ins one by one; The plugin execution module finds the WebAssembly ID from the plugin definition module, finds the corresponding WebAssembly in the WebAssembly storage, loads the WebAssembly binary code, instantiates the WebAssembly, and calls the method executed in the WebAssembly specified in the plugin definition.

9. A system for calling a WebAssembly plug-in in an API request pipeline according to claim 8, characterized in that: The plugin definition contains: The plug-in matching rule module is used to determine whether a specific API request needs to call this plug-in; The plugin call location module is used to indicate whether the plugin is called before or after the API action is executed; The sorting module called by the plug-in. When the same API request needs to call multiple plug-ins at the same location, they are called in sorted order; WebAssembly ID module: finds the corresponding WebAssembly binary content in the WebAssembly storage through the WebAssembly ID; WebAssembly function name module: When a WebAssembly contains multiple callable methods, define multiple plug-ins to reuse the WebAssembly and reduce the number of WebAssembly.

Images