怎么建立一个自己的网站wordpress广告管理

大家好！

距离上次更新已经过去一段时间了，这段日子里我们一直在酝酿新的功能，本次的迭代将给大家带来 6 大插件的更新~一起来看看有哪些变化吧！

新特性

1. 新增 额外参数v2 插件，支持对转发参数进行加密、拼接等操作。

该插件为额外参数插件的升级版本，在v1版本中，我们只能设置静态参数转发给上游服务，存在一定的局限性。

在某些场景，如：对参数进行签名、加密等操作，v1版本无法完成。

额外参数 v2 在 v1 版本的基础上，新增了以下功能特性：

• 支持引用系统变量（如：请求URI、应用名称等），记录客户端请求特性。
• 支持对参数进行动态处理。如：md5加密、字符串拼接、获取当前请求时间戳和日期等动态操作。

以字符串拼接为例，我们希望通过拼接请求体参数 name、version、driver 的方式，生成 x-apispace-token 头部，插件配置如下：

{"params": [{"name": "x-apinto-token","position": "header","type": "$concat","value": ["{name}","{version}","{driver}"]}],"request_body_type": "json"
}

客户端请求体内容如下：

{"name":"apinto","version":"v1","driver":"http"
}

经过 Apinto 转发，后端服务收到的请求头 x-apinto-token 为：

apintov1http

2. 新增 次数扣减 插件，可根据不同用户配置计数扣减，对API调用进行计数限制。

假设你经营一家超市，每个顾客购物时需要使用购物袋。为了管理超市的容量和资源，你设置了每个顾客最多可以使用的购物袋数量。这个限制就类似于次数扣减，在 API 网关中，每个请求都会消耗一定的次数。

超市代表 API 网关，顾客代表发起 API 请求的客户端，购物袋代表可用的请求配额。次数扣减确保 API 请求的数量保持在可接受的限制范围内，防止过载，并确保资源的公平分配，就像超市限制购物袋数量一样，防止过度使用。

当可用次数用完时，可以通过购买额外的请求次数或根据特定条件自动充值来增加可用的请求配额。

Apinto 网关支持以下两种次数扣减方式：

• 对单一请求进行单次计数：每成功转发一次，计数为1次。
• 对单一请求进行批量计数：可配置参数拆分规则，如短信接口，参数 phone 允许输入多个手机号码，此时根据批量扣次的规则，计数为手机号码个数。

次数扣减架构图如上，该插件依赖 Redis 集群进行次数扣减同步，在配置该插件前，需要部署好 Redis 集群并在 Apinto 控制台配置并发布 Redis 配置，如下图：

3. 新增 参数校验 插件，拦截无效请求。

该插件支持校验请求体 、请求头部 、Query 参数 的有效性和合法性，过滤/拦截无效请求。在进行参数校验时，支持正则表达式校验、前缀校验、后缀校验、包含校验、全等校验、为空校验等多种校验方式。

参数校验插件执行简化流程图如下，该图省略路由匹配、剩余插件执行等操作。

4. 新增 请求体校验 插件，限制请求体大小。

当客户端向服务器发送请求时，请求体中可能包含大量的数据，如文件上传、表单提交等。如果没有对请求体大小进行限制，那么客户端可以发送非常大的请求体，这可能导致网络拥塞，影响其他用户的访问速度和体验；其次，处理大量的请求体数据会消耗服务器的计算和存储资源，降低服务器的性能和响应速度。

同时，恶意用户可能利用大请求体来进行拒绝服务（Denial of Service）攻击，通过消耗服务器资源来使其无法正常工作。因此，通过限制请求体大小，可以有效地控制网络流量、保护服务器资源和防止潜在的安全威胁。

5. 新增 格式转换 插件，支持 JSON 与 XML 数据格式互转。

XML 和 JSON 是目前主要的两种数据交换格式。

由于历史原因，一些后端服务系统采用SOAP协议开发，使用XML作为数据通讯格式。

现在大多数行业中的开放 API 都使用JSON格式进行通信。然而，由于后端服务技术过时，无法进行改造。

为了向用户提供更便利的调用方式，我们可以使用格式转换插件来解决JSON和XML之间的互转问题。这样，我们就能够通过JSON格式开放给用户调用，同时与后端服务系统进行无缝交互。

当客户端请求体为JSON时，经过 Apinto 网关后，将会将数据转换成XML发送给后端服务；接收到后端服务返回的XML后，Apinto 将会把该内容转成JSON返回给客户端，如下图所示：

同理，当客户端请求体为XML时，也会自动转换成JSON发送给后端服务。

6. 新增 响应体重写v2 插件。

当匹配响应状态码、响应体、响应头部后，重写响应信息。不仅支持对上游服务返回的响应进行重写，而且支持对插件报错设置的默认响应进行重写。

对上游服务返回的响应流程图如下：

建议将该插件执行顺序尽量靠前，如下图：

写在最后

目前 Apinto 及其周边项目已经开源，我们希望通过 Apinto 强大的插件拓展能力，用户可像乐高积木一样根据需要自行拓展 Apinto 的插件，以满足不同的业务市场需求。

Apinto 目前属于萌芽阶段，我们希望集合广大开源爱好者的力量，与大家一起讨论方案，接受大家的批评指正，一起将产品打磨完善，做下一个端与端间的Traffic Middleware。这是一个开放和积极的项目，我们诚挚地邀请您一起参与到我们的项目开源工作中。每一个贡献都是有意义的，包括但不限于：

·查找 bugs，取得性能上的提升

·帮助完善文档，提供用户操作体验

·提交你们的 issue，让我们知道您的奇思妙想

·参与自定义插件的开发，丰富 Apinto 的能力

...

欢迎各位开源爱好者参与到 Apinto 项目中，和我们一起为开源事业贡献自己的力量！

Apinto GitHub ：https://github.com/eolinker/apinto