继续上一篇，我们来研究request-transformer插件，这个插件主要是用来对Request的请求做转换，包含转换request的几个内容：

1、 http method: replace(替换)，替换原有的method，改变对上游服务的method方法

2、 body:remove(移除)、rename(重命名)、replace(替换)、add(增加)、append(追加)

3、 headers:remove(移除)、rename(重命名)、replace(替换)、add(增加)、append(追加)

4、 querystring:remove(移除)、rename(重命名)、replace(替换)、add(增加)、append(追加)

5、 uri: replace(替换),替换原有的uri,改变路由到的上游服务地址。

一、 首先我们来测试http method,我们增加业务服务的POST方法路由，但是通过该插件将POST方法的路由修改为对原服务的GET方法，配置如下：

然后用POSTMAN调用路由地址的POST服务，得到原服务的GET方法返回的消息：

二、 我们来测试上面第五项URI的转换，我们将业务服务调用URI指向另外一个API。

原服务URI地址如上。

插件Replace的URI如上。配置完成后使用POSTMAN调用服务。

三、 我们再来测试一下针对Request的body的各类方法，为了更好的了解Replace、Rename等操作对于Request的更改效果，我们构建一个原生服务来监控网关更改了Request之后的输出。

1、首先使用POSTMAN调用该服务代理地址后得到控制台的输出：

2、我们在该服务上增加request-transformer插件，并先request的body的rename、replace和remove操作，设置界面如下图：

调用网关的request的body和插件转换之后调用原服务的request的body对比如下：

 从以上结果我们看到，remove属性和值被移除了，rename属性名被修改成了rename2, replace的值从xxxx被修改成了wanzhetao。这三个转换起了作用。

接下来我们再来验证下add和append，首先我们在add和append中都增加配置：

然后来看得到的结果如下：

我们发现，append增加属性值为Array，而add增加的属性值为文本。Add增加的属性如果已经存在于Request的body中，则add是不起作用的。但是append如果request的body存在同名属性，且属性值为Array, 则会将转换的内容添加到Array中去，这就是两者不一样的地方。我们来看一下append的内容追踪功能验证：

调用body中增加a2:[ "cxcx"]，转换插件中也存在a2:wwwww,那么经过调后用我们查看Request的转换结果如下：

可以看到a2中追踪了我们在request转换插件中配置的内容。

验证完body之后，Request的querystring和headers也是同样的道理就不再一一验证了。对于这个插件，再多说一句，插件中最重要的就是在网关对于数据转换的场景，比如原来有的一个系统要做接入，可是目前网关的服务规范和待接入的API不太一样，需要做转换，那么最常用的就是通过rename来实现属性映射，后面我会专门针对此类应用场景进行讲解。