Method, control device and computer-readable storage medium for modifying request body by gateway

Abstract

The present application discloses a method, a control device, and a computer-readable storage medium for modifying a request body by a gateway, and relates to the field of smart home / intelligent home technology. The method for modifying a request body by a gateway includes: receiving a configuration file about a filter; using a configuration class in a custom filter factory to convert the class name of the configuration file into an internal class and an external class; and modifying and parsing the request body based on the internal and external classes and the implementation class of the custom functional interface in the custom filter factory. In implementing the technical solution of the present invention, by customizing the configuration class and setting the functional interface, parameters can be configured in the configuration file, just like the filter factories provided by other Spring Cloud gateways, and the configuration file parameters can be read in the custom filter factory, and the instantiation parameters can be loaded, so as to achieve the purpose of using configuration files in other languages ​​to configure and modify the request body filter in the same way, and in a more flexible and traversable manner.

Description

Technical Field

[0001] The present invention relates to the field of microservice gateways, and specifically provides a method for modifying a request body of a gateway, a control device, and a computer-readable storage medium. Background Art

[0002] In the existing technology, modification of the request body often requires a configuration file in a specific language to modify the request body in the gateway. However, using a configuration file in a specific language increases the limitations of modifying the request body. Here, SpringCloud Gateway (microservice gateway component) is used as an example.

[0003] Spring Cloud Gateway provides basic gateway functionality based on a filter chain approach. It provides many built-in filter factories, including one that modifies the request body. Filters that modify the request body can be used to modify the request body before the network management system sends it downstream. Configuring filters in configuration files is a benefit Spring Cloud Gateway offers developers. However, according to the official documentation, filters that modify the request body can only be configured using the Java DSL.

[0004] Existing methods for preprocessing request bodies in Spring Cloud Gateway include defining a global filter that retrieves and preprocesses the request body before forwarding it. This approach neither overcomes the limitation of Java DSL configuration nor achieves the goal of configuring personalized request body filters for each route. Another approach is to use the default filter factory provided by Spring Cloud Gateway, which is specifically designed for modifying request bodies, to modify the request body gateway filter factory used to generate filters for processing request bodies. This approach can only be configured through Java DSL, as described in the official documentation. However, using only Java DSL for configuration is restrictive, making the file inflexible and limited.

[0005] Accordingly, this field requires a new technical solution to solve the above problems. Summary of the Invention

[0006] In order to overcome the above-mentioned defects, the present invention is proposed to provide a solution or at least partially solve the technical problem in the prior art that the request body can only be modified through a configuration file in a specific language.

[0007] In a first aspect, the present invention provides a method for a gateway to modify a request body, the method comprising:

[0008] Receive configuration files about filters;

[0009] Use the configuration class in the custom filter factory to convert the class name of the configuration file into inner and outer classes;

[0010] Modify and parse the request body based on internal and external classes and custom functional interface implementation classes in custom filter factories.

[0011] Furthermore, the custom factory is generated based on the filter factory.

[0012] Furthermore, the configuration class also includes: content type and rewrite function in the rewrite class and modifiers corresponding to the two variables.

[0013] Furthermore, the class name of the configuration file is converted into an inner class and an outer class using the configuration class in the custom filter factory, including:

[0014] Get the class name of the configuration in the configuration file based on the modifier parsing;

[0015] Assign class names to inner and outer classes.

[0016] Furthermore, the modifying and parsing the request body based on the internal and external classes and the implementation class of the customized functional interface in the customized filter factory includes: modifying and parsing the request body based on the internal and external classes and the implementation class of the customized rewriting class in the customized filter factory.

[0017] Furthermore, the modification and parsing of the request body based on the internal and external classes and the implementation class of the customized functional interface in the customized filter factory includes:

[0018] Receive the request body;

[0019] Pass the request body into the application method of the custom rewriting class;

[0020] Pass the preset class into the application method of the custom overridden class;

[0021] Modify and parse the request body.

[0022] Furthermore, the configuration class also includes: accessors for all the variables.

[0023] In a second aspect, the present invention provides a system for modifying a request body via a gateway, the system comprising:

[0024] Receiving module: receiving the configuration file about the filter;

[0025] Conversion module: Use the configuration class in the custom filter factory to convert the class name of the configuration file into internal and external classes;

[0026] Processing module: Modifies and parses the request body based on internal and external classes and the implementation class of the custom functional interface in the custom filter factory.

[0027] In a third aspect, a control device is provided, which includes a processor and a storage device, wherein the storage device is suitable for storing multiple program codes, and the program codes are suitable for being loaded and run by the processor to execute the method for modifying the request body of the gateway described in any technical solution of the above-mentioned method for modifying the request body of the gateway.

[0028] In a fourth aspect, a computer-readable storage medium is provided, which stores a plurality of program codes, wherein the program codes are suitable for being loaded and run by a processor to execute the method for modifying a request body of a gateway as described in any one of the technical solutions of the method for modifying a request body of the gateway.

[0029] The above one or more technical solutions of the present invention have at least one or more of the following beneficial effects:

[0030] In the technical solution of the present invention, by customizing the configuration class and setting the functional interface, parameters can be configured in the configuration file for different routes, just like the filter factories provided by other Spring Cloud gateways. The configuration file parameters are read in the custom filter factory and the instantiation parameters are loaded, thereby achieving the purpose of using configuration files in other languages ​​to configure and modify the request body filter in the same way, and it is more flexible and traversable. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0032] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0033] Figure 1 This is a schematic flow chart of the main steps according to one embodiment of the present invention;

[0034] Figure 2 is a sub-diagram of a step flow according to an embodiment of the present invention;

[0035] Figure 3 It is a sub-diagram of the step flow according to one embodiment of the present invention. DETAILED DESCRIPTION

[0036] In order to enable those skilled in the art to better understand the present invention, the following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the drawings 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 in the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of this application.

[0037] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequential order. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in a sequence other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0038] Here we first explain some terms involved in the present invention.

[0039] Configuration files: Configuration files are used to configure parameters and initial settings for certain computer programs. They are used for user applications, server processes, and operating system settings. In Spring CloudGateway, filters that respond to functions are obtained through configuration files.

[0040] Request Body: The request body, also called the request body, is the data sent by the client to the API. In contrast, the response body is the data sent by the API to the client.

[0041] Spring Cloud Gateway: Spring Cloud Gateway is an API gateway used in microservices architecture. Specifically, Spring Cloud Gateway operates as follows.

[0042] The Gateway Client sends a request to Spring Cloud Gateway. It is first extracted and assembled into a gateway context by the HttpWeb HandlerAdapter. The gateway context is then passed to the Dispatcher Handler, which dispatches the request to the RoutePredicateHandlerMapping. The RoutePredicateHandlerMapping is responsible for route lookup and determines whether the route is available based on the route predicate. If the predicate succeeds, the FilteringWebHandler creates a filter chain and invokes the request through a request-specific filter chain. The filter can run logic before (pre) and after (post) the proxy request. All pre-filter logic is executed before the proxy request is made. After the proxy request is issued, the post filter logic is run. After processing, the response body is returned to the Gateway client. Modifying the request body in Spring Cloud Gateway can be achieved through filters, but existing technologies only use the Java DSL to configure and modify filters, which is not flexible enough.

[0043] To facilitate understanding of the present invention, an application scenario is provided herein to facilitate understanding of the content of the present invention. In this implementation, a method for modifying a request body by a gateway proposed in the present invention is used in a Spring Cloud environment.

[0044] See attached Figure 1-3 , Figure 1 FIG. 1 is a flow chart showing the main steps of a method for modifying a request body by a gateway according to an embodiment of the present invention. Figure 1 As shown, a method for modifying a request body by a gateway in an embodiment of the present invention mainly includes the following steps S10 to S30.

[0045] Step S10: Receive a configuration file about the filter.

[0046] In this embodiment, the configuration file is a file used to modify the request body filter. The request body filter needs to configure the parameters in the configuration file, and needs to read the configuration file parameters in the filter factory and load the instantiation parameters, so as to modify the request body as required before sending the request body to the downstream. Instantiation refers to the process of creating objects using classes in object-oriented programming. From another perspective, instantiation is the process of making an abstract concept class specific to the physical object of that class. The instantiation process is generally composed of class name object name = new class name (parameter 1, parameter 2... parameter n). For example, Date date = new Date(), in the above process, a date object is created using the date class, and this process is called object instantiation.

[0047] In this embodiment, the configuration file includes the type of the configuration file, the environment variables of the configuration file, and the preset startup conditions. Generally speaking, the configuration file is usually in the Javajson format, but the format of the configuration file in this embodiment is not limited to Javajson, and configuration files in other formats can also be used. Here is a brief description of the class name. The Java class name naming rule is that the first letter must start with a letter, and the subsequent characters can be any combination of letters and numbers. C++ class names are also in the form of strings.

[0048] Step S20: using the configuration class in the custom filter factory to convert the class name of the configuration file into an inner class and an outer class.

[0049] In this embodiment, the custom factory refers to a custom filter factory. The configuration class is the config class, the inner class is the inClass class within the config class, the outer class is the outClass class within the config class, the modifier is the setter method of a function or variable, and the accessor is the getter method of a function or variable. The overriding class is ReweiteFunction, the overriding function is reweiteFunction, and is the name of the function under the overriding class. The filter factory is AbstractGatewayFilterFactory, and the apply method is the apply method corresponding to the function. The config class is an inner class of the custom factory, and the setter method is used to retrieve the value of the variable.

[0050] In one implementation, a custom factory is generated based on AbstractGatewayFilterFactory, specifically inheriting the abstract class AbstractGatewayFilterFactory in Spring Cloud Gateway. When creating a custom filter factory, you need to initialize the config class. In this embodiment, the inner config class includes: Class inClass, Class outClass, String contentType, and RewriteFunctionreweiteFunction, as well as the corresponding setter and getter methods. The setter method of rewriteFunction takes a parameter of the RewriteFunction type.

[0051] Some codes are given here to facilitate understanding of this implementation.

[0052]

[0053]

[0054] In order to convert the class name into a preset class, this embodiment provides a specific implementation including steps S201-S202 for completing the conversion, such as Figure 2 As shown, the details are as follows:

[0055] Step S201: Obtain the class name of the configuration in the configuration file based on the modifier parsing.

[0056] In this embodiment, the setter method is also a setter set in the config class, and a constructor is also set. When defining the variables in the custom config class: Class inClass, ClassoutClass, String contentType, and ReweiteFunction reweiteFunction, the corresponding constructors are declared. Constructors are used to create and initialize objects. It should be noted that each of these variables has at least one corresponding constructor. If no additional constructors are set, a default constructor is generated, and the constructor's modifiers are the same as those of the class.

[0057] Step S202: Assign class names to the inner class and the outer class.

[0058] In this embodiment, the pre-set class refers to class names converted to inclass and outclass in a custom config class via setter methods. When registering a gateway filter using configuration, the filter must be registered with the routes previously defined in the application properties. The setter methods are the setters configured in the config class. The setters inject the set values ​​into the corresponding properties of the inner class. For ease of understanding, using @ConfigurationPropertiesprefix="person" as an example, the class name starting with "person" in the configuration file is injected into the corresponding properties of the config class (i.e., inclass and outclass) via setter methods.

[0059] Specifically, in this embodiment, Class inClass uses the Java class loading mechanism for the class name in the form of a string configured in the configuration file, calls the Class's forName method, loads the class corresponding to the class name, and assigns the loaded class to inClass. The class loading mechanism in Java refers to the virtual machine loading the data describing the class from the Class file into the memory, and verifies, converts, parses and initializes the data, and finally forms a Java type that can be used directly by the virtual machine. In this embodiment, a class object, that is, a class, will be generated. Similarly, Class outClass uses the Java class loading mechanism for the class name in the form of a string configured in the configuration file, calls the Class's forName method, loads the class corresponding to the class name, and assigns the loaded class to outClass. In summary, in this embodiment, the setter method parameters of the variables inclass and outclass are full path names of string type, and the class loading method is used in the method implementation to load the class with the full path class name.

[0060] It should be noted that the four variables in the config class are all the same as those defined in the ModifyResponseBodyGatewayFilterFactory. That is, the custom factory in this embodiment is a filter factory that modifies the request body according to the definition of ModifyResponseBodyGatewayFilterFactory, where the filter factory in this embodiment inherits the abstract class AbstractGatewayFilterFactory in Spring Cloud gateway, where the generic is the inner class config class of the custom factory. Generics are a special type that postpones the work of clarifying the type until the object is created or the method is called. That is to say, in the process of using generics, the data type of the operation is specified as a parameter, and this parameter type can be used in classes, methods and interfaces. Some code is given here. The setter method in this embodiment is a method for updating the value of a variable. The getter method is a method for reading the value of a variable. To facilitate the understanding of this embodiment, some code is given here to help understand this embodiment.

[0061]

[0062] Step S30: modify and parse the request body based on the internal and external classes and the implementation class of the customized functional interface in the customized filter factory.

[0063] In this embodiment, a custom functional interface is used to receive the request body and complete the transfer. The preset class refers to the assigned inclass and outclass.

[0064] In one embodiment, a custom function interface is used as an example to illustrate. In this embodiment, config is a generic type, and its internal member variables and function return values ​​can also be generic. Function is also a generic class, which has two generic parameters: input parameters and return results.

[0065] In this implementation, the RequestBody needs to be rewritten, using RewriterFunction. Specifically, the request body is modified and parsed based on the implementation class of the custom functional interface in the internal and external classes and the custom filter factory. This includes modifying and parsing the request body based on the implementation class of the custom rewriting class in the internal and external classes and the custom filter factory.

[0066] In this embodiment, a specific method is proposed, including steps S301-S304, such as Figure 3 As shown, the details are as follows:

[0067] Step S301: Receive the request body.

[0068] In this example, the request body is sent from the client to the API Gateway. It is first received by the GatewayHandlerMapping and, if the assertion succeeds, is passed to the FilteringWebHandler. This creates a filter chain and runs the request through the request-specific filter chain. At this point, the inclass and outclass values ​​in the config have been assigned, and the response configuration has been parsed and completed.

[0069] Step S302: pass the request body into the application method of the custom rewriting class.

[0070] Step S303: passing the preset class into the application method of the custom rewriting class.

[0071] In this implementation, the default classes are the inclass and outclass after assignment. In the apply method of RewriterFunction, in class and out class are passed in as parameters.

[0072] Step S304: Modify and parse the request body.

[0073] In this embodiment, the apply method of RewriterFunction is implemented by customizing the implementation class of RewriterFunction. Since the setter method of RewriterFunction has been set in the config class, it is understandable that in this embodiment, RewriterFunction is used as the implementation class of the native RewriterFunction interface of Spring Cloud Gateway. Therefore, the request body can be obtained through the body parameter in the apply method. The request body is injected into the Spring container. The reading method is to read the request body using the setter method of RewriterFunction and assign it to RewriterFunction. Finally, RewriterFunction is injected into the Spring container as a Bean. It should be noted here that the implementation class of the customized RewriterFunction is to define different implementation classes according to the needs, so as to perform different preprocessing on the request body. The rewriterFunction is configured using the #{@beanName} method in the configuration file.

[0074] Furthermore, in order to better understand the working principle of this embodiment, the overall step flow is reviewed from the perspective of a custom factory, that is, from the perspective of a custom filter factory.

[0075] When the project is started, the filter factory has been instantiated. The simple understanding is that a custom filter factory has been created. When initializing the filter factory, it will also initialize the config class, and when initializing the config, it will also initialize the function at the same time.

[0076] The role of the Config class in a custom filter factory: When the Spring container starts a project, loads a class, or reads a configuration file, it reads the required information from the routing and configuration files into the Spring container. After reading the information, it calls the getter and setter methods (getinclass, setoutclass) in the custom Config class to assign the values ​​in the read configuration file to the in class and out class in the Config class.

[0077] To facilitate understanding, a simple analogy is provided here to illustrate the above assignment process. It can be understood as the Spring container simply reading a string. Then, when the Spring container calls the configsetter method, it loads the string into a class through the setter method and assigns it to the inclass or outclass properties. That is, the setter method is called to parse the configured class name string in the configuration file, and then the configured class name string is loaded into the corresponding inclass or outclass class and assigned to these two properties.

[0078] Later, when a program runs, the route reaches the API gateway, and a match occurs between the route and the filter factory. This means that the corresponding path matches the current path. The filter factory method is then run, and the RewriteFunction method is called. The request reaches the filter factory, and the function has an apply method, in which the inclass and outclass are passed as parameters. The request body is then passed to the apply method of that function, and the request body can be modified and parsed according to the configuration file.

[0079] It should be pointed out that although the various steps in the above embodiments are described in a specific order, those skilled in the art will understand that in order to achieve the effects of the present invention, different steps do not have to be performed in such an order. They can be performed simultaneously (in parallel) or in other orders. These changes are within the scope of protection of the present invention.

[0080] Furthermore, the present invention also provides a system for modifying a request body by a gateway, comprising: a receiving module, a conversion module, and a processing module.

[0081] Receiving module: receiving the configuration file about the filter.

[0082] In the receiving module, the configuration file is used to modify the request body filter. The request body filter needs to configure the parameters in the configuration file, and needs to read the configuration file parameters in the filter factory and load the instantiation parameters to modify the request body as required before sending it downstream. Instantiation refers to the process of creating objects using classes in object-oriented programming. From another perspective, instantiation is the process of making an abstract concept class specific to the physical object of that class. The instantiation process is generally composed of class name object name = new class name (parameter 1, parameter 2... parameter n). For example, Date date = new Date(), in the above process, a date object is created using the date class. This process is called object instantiation.

[0083] Furthermore, the configuration file of the configuration file includes the type of the configuration file, the environment variables of the configuration file, and the preset startup conditions. Generally speaking, the configuration file is usually in the Javajson format, but the format of the configuration file in this embodiment is not limited to Javajson, and configuration files in other formats can also be used. Here is a brief description of the class name. The Java class name naming rule is that the first letter must start with a letter, and the subsequent characters can be any combination of letters and numbers. The class name of C++ is also in the form of a string.

[0084] Conversion module: Use the configuration class in the custom filter factory to convert the class name of the configuration file into internal and external classes;

[0085] In the conversion module, the custom factory is generated based on AbstractGatewayFilterFactory, specifically inheriting the abstract class AbstractGatewayFilterFactory in Spring Cloud Gateway. When creating a custom filter factory, you need to initialize the config class. In this embodiment, the inner config class includes: Class inClass, Class outClass, String contentType, and RewriteFunctionreweiteFunction, as well as the corresponding setter and getter methods. The setter method of rewriteFunction takes a parameter of the RewriteFunction type.

[0086] In order to convert the class name into a preset class, this embodiment provides a specific implementation including a first reading module and a first conversion module, as follows:

[0087] The first reading module: obtains the configured class name in the configuration file based on the modifier parsing.

[0088] In this embodiment, the setter method is also a setter set in the config class. A constructor should also be set at the same time. When defining the variables in the custom config class: Class inClass, ClassoutClass, String contentType, and ReweiteFunction reweiteFunction, the corresponding constructors are declared. The function of the constructor is to create and initialize objects. It should be noted that each of the above variables has at least one corresponding constructor. If no additional constructors are set, a default constructor is generated. The constructor's modifiers are the same as those of the class.

[0089] The first conversion module: assign class names to inner classes and outer classes.

[0090] In the first conversion module, converting the class name into the preset class means converting the class name into inclass and outclass in the custom config class through the setter method. When registering the gateway filter with the configuration, the filter needs to be registered to the route previously defined in the application properties, where the setter method is the setter set in the config class. The setter will inject the set value into the corresponding attribute of the inner class. For ease of understanding, taking @ConfigurationPropertiesprefix="person" as an example, the class name starting with person in the configuration file is injected into the corresponding attribute of the config class through the setter method, namely inclass and outclass.

[0091] Specifically, in this embodiment, Class inClass uses the Java class loading mechanism for the class name in the form of a string configured in the configuration file, calls the Class's forName method, loads the class corresponding to the class name, and assigns the loaded class to inClass. The class loading mechanism in Java refers to the virtual machine loading the data describing the class from the Class file into the memory, and verifies, converts, parses and initializes the data, and finally forms a Java type that can be used directly by the virtual machine. In this embodiment, a class object, that is, a class, will be generated. Class outClass uses the Java class loading mechanism for the class name in the form of a string configured in the configuration file, calls the Class's forName method, loads the class corresponding to the class name, and assigns the loaded class to outClass. In summary, in this embodiment, the setter method parameters of the variables inclass and outclass are full path names of string type, and the class loading method is used in the method implementation to load the class with the full path class name.

[0092] It should be noted that the four variables in the config class are all the same as those defined in the ModifyResponseBodyGatewayFilterFactory. That is, the custom factory in this embodiment is a filter factory that modifies the request body according to the definition of ModifyResponseBodyGatewayFilterFactory, where the filter factory in this embodiment inherits the abstract class AbstractGatewayFilterFactory in Spring Cloud gateway, where the generic is the inner class config class of the custom factory. Generics are a special type that postpones the work of clarifying the type until the object is created or the method is called. That is to say, in the process of using generics, the data type of the operation is specified as a parameter, and this parameter type can be used in classes, methods and interfaces. Some code is given here. The setter method in this embodiment is a method for updating the value of a variable. The getter method is a method for reading the value of a variable.

[0093] Processing module: Modifies and parses the request body based on internal and external classes and the implementation class of the custom functional interface in the custom filter factory.

[0094] In this embodiment, a custom functional interface is used to receive the request body and complete the transfer. The preset class refers to the assigned inclass and outclass.

[0095] In one embodiment, a customized function interface is used as an example for illustration. In this embodiment, config is generic, and its internal member variables and function return values ​​can be generic. Function is also a generic class, which has two generic parameters, input parameters and return results. In this embodiment, it is necessary to rewrite Requestbody (request body), and RewriterFunction is used. That is, the implementation class of the customized functional interface based on internal and external classes and the customized filter factory modifies and parses the request body, including: the implementation class of the customized rewriting class based on internal and external classes and the customized filter factory modifies and parses the request body. A specific method is proposed in this embodiment, which is as follows:

[0096] The second receiving module: receives the request body.

[0097] In the second receiving module, the request body is sent from the client to the API Gateway. It is first received by the GatewayHandlerMapping. If the assertion succeeds, it is passed to the FilteringWebHandler. Then, a filter chain is created and the request is run through the request-specific filter chain. At this point, the inclass and outclass values ​​in the config have been assigned, and the response configuration has been parsed and completed.

[0098] The second conversion module: passes the request body into the application method of the custom rewriting class.

[0099] The third conversion module: passes the preset class into the application method of the custom rewriting class.

[0100] In this implementation, the default classes are the inclass and outclass after assignment. In the apply method of RewriterFunction, in class and out class are passed in as parameters.

[0101] The first processing module: modify and parse the request body.

[0102] In the first processing module, the RewriterFunction's apply method is implemented by customizing the RewriterFunction implementation class. Since the rewriterFunction setter method has been set in the config class, it is understandable that in this implementation, rewriterFunction is used as the implementation class of Spring Cloudgateway's native RewriterFunction interface. Therefore, the request body can be obtained through the body parameter in the apply method. The request body is injected into the Spring container, where the reading method is to read the request body using the rewriterFunction setter method and assign it to the rewriterFunction. Finally, the rewriterFunction is injected into the Spring container as a Bean. It should be noted here that the custom RewriterFunction implementation class is to define different implementation classes according to requirements, so as to perform different preprocessing on the request body. The rewriterFunction is configured using the #{@beanName} method in the configuration file.

[0103] Those skilled in the art will appreciate that all or part of the processes in the method for implementing the above-mentioned embodiment of the present invention may also be accomplished by instructing the relevant hardware through a computer program. The computer program may be stored in a computer-readable storage medium. When the computer program is executed by a processor, it may implement the steps of each of the above-mentioned method embodiments. The computer program includes computer program code, which may be in source code form, object code form, executable file, or some intermediate form. The computer-readable storage medium may include: any entity or device, medium, USB flash drive, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory, random access memory, electric carrier signal, telecommunication signal, and software distribution medium capable of carrying the computer program code. It should be noted that the content contained in the computer-readable storage medium may be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable storage media do not include electric carrier signals and telecommunication signals.

[0104] Furthermore, the present invention also provides a control device. In one embodiment of the control device according to the present invention, the control device includes a processor and a storage device. The storage device can be configured to store a program for executing the method for modifying the request body of the gateway according to the above method embodiment, and the processor can be configured to execute the program in the storage device, which includes but is not limited to a program for executing the method for modifying the request body of the gateway according to the above method embodiment. For ease of explanation, only the parts related to the embodiment of the present invention are shown. For specific technical details not disclosed, please refer to the method part of the embodiment of the present invention. The control device can be a control device device formed by various electronic devices.

[0105] Furthermore, the present invention also provides a computer-readable storage medium. In a computer-readable storage medium embodiment according to the present invention, the computer-readable storage medium can be configured to store a program for executing the method for modifying the request body of the gateway in the above-mentioned method embodiment. The program can be loaded and run by the processor to implement the above-mentioned method for modifying the request body of the gateway. For ease of explanation, only the parts related to the embodiment of the present invention are shown. For specific technical details not disclosed, please refer to the method part of the embodiment of the present invention. The computer-readable storage medium can be a storage device formed by various electronic devices. Optionally, the computer-readable storage medium in the embodiment of the present invention is a non-transitory computer-readable storage medium.

[0106] Furthermore, it should be understood that since the setting of each module is only for the purpose of illustrating the functional units of the device of the present invention, the physical devices corresponding to these modules may be the processor itself, or a part of the software in the processor, a part of the hardware, or a part of the combination of software and hardware. Therefore, the number of each module in the figure is only schematic, and the method is widely used in smart home (Smart Home), smart home, smart home device ecology, smart residence (Intelligence House) ecology and other whole-house intelligent digital control application scenarios. The above-mentioned network may include but is not limited to at least one of the following: wired network, wireless network. The above-mentioned wired network may include but is not limited to at least one of the following: wide area network, metropolitan area network, local area network, and the above-mentioned wireless network may include but is not limited to at least one of the following: WIFI (Wireless Fidelity, Wireless Fidelity), Bluetooth. The terminal devices may include but are not limited to PCs, mobile phones, tablet computers, smart air conditioners, smart range hoods, smart refrigerators, smart ovens, smart stoves, smart washing machines, smart water heaters, smart washing equipment, smart dishwashers, smart projection equipment, smart TVs, smart clothes drying racks, smart curtains, smart audio and video, smart sockets, smart speakers, smart speakers, smart fresh air equipment, smart kitchen and bathroom equipment, smart bathroom equipment, smart sweeping robots, smart window cleaning robots, smart mopping robots, smart air purification equipment, smart steamers, smart microwave ovens, smart kitchen treasures, smart purifiers, smart water dispensers, smart door locks, etc.

[0107] Those skilled in the art will appreciate that the various modules in the device can be adaptively split or merged. Such splitting or merging of specific modules does not cause the technical solution to deviate from the principles of the present invention. Therefore, the technical solutions after splitting or merging will fall within the scope of protection of the present invention.

[0108] Thus far, the technical solutions of the present invention have been described in conjunction with the preferred embodiments shown in the accompanying drawings. However, it will be readily understood by those skilled in the art that the scope of protection of the present invention is obviously not limited to these specific embodiments. Without departing from the principles of the present invention, those skilled in the art may make equivalent changes or substitutions to the relevant technical features, and the technical solutions after such changes or substitutions will fall within the scope of protection of the present invention.

Claims

1. A method for modifying a request body by a gateway, characterized in that: include: Receive configuration files about filters; Use the configuration class in the custom filter factory to convert the class name of the configuration file into inner and outer classes; The request body is modified and parsed based on the implementation class of the custom functional interface in the inner class, the outer class and the custom filter factory, including: modifying and parsing the request body based on the implementation class of the custom rewriting class in the inner class, the outer class and the custom filter factory.

2. The method for modifying a request body by a gateway according to claim 1, wherein: The custom filter factory is generated based on the filter factory.

3. The method for modifying a request body by a gateway according to claim 2, wherein: The configuration class also includes: The content type and the rewriting function in the rewriting class and the modifiers corresponding to the two variables.

4. The method for modifying a request body by a gateway according to claim 1, wherein: Use the configuration class in your custom filter factory to convert the class name of said configuration file into inner and outer classes, including: Get the class name of the configuration in the configuration file based on the modifier parsing; Assign class names to inner and outer classes.

5. The method for modifying a request body by a gateway according to any one of claims 1 to 4, characterized in that: The request body is modified and parsed based on the implementation class of the custom functional interface in the inner class, the outer class and the custom filter factory: Receive the request body; Pass the request body into the application method of the custom rewriting class; Pass the preset class into the application method of the custom rewriting class, where the preset class refers to the inner class and the outer class; Modify and parse the request body.

6. The method for modifying a request body by a gateway according to claim 3, wherein: The configuration class also includes: accessors for all the variables.

7. A system for modifying a request body by a gateway, characterized in that: include: Receiving module: receiving the configuration file about the filter; Conversion module: Use the configuration class in the custom filter factory to convert the class name of the configuration file into internal and external classes; Processing module: Modifies and parses the request body based on the implementation class of the inner class, outer class, and custom rewriting class in the custom filter factory.

8. A control device comprising a processor and a storage device, wherein the storage device is adapted to store a plurality of program codes, wherein: The program code is suitable for being loaded and run by the processor to execute the method for modifying a request body by a gateway as described in any one of claims 1-6.

9. A computer-readable storage medium storing a plurality of program codes, characterized in that: The program code is suitable for being loaded and run by a processor to execute the method for modifying a request body by a gateway as described in any one of claims 1-6.

Images