绵阳商城网站建设,前端seo搜索引擎优化,企业营销理念,伪静态网站搬迁大家好#xff01;
距离上次更新已经过去一段时间了#xff0c;这段日子里我们一直在酝酿新的功能#xff0c;本次的迭代将给大家带来 6 大插件的更新~一起来看看有哪些变化吧#xff01; 新特性
1. 新增 额外参数v2 插件#xff0c;支持对转发参数进行加密、拼接等操作…大家好
距离上次更新已经过去一段时间了这段日子里我们一直在酝酿新的功能本次的迭代将给大家带来 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
