对于 api 网关来说，两种设计，哪种更适合

[dzdh]

是酱，觉得市面上的 api 网关都太产品化，难用（配置麻烦），所以用 spring cloud gateway 自己开发了一套网关。

然后对实现形式上，有一些争议，主要体现在规范、管理上。 比如：

第一种，像支付宝一样

openapi.x.com/gateway.do?method=api.name.and.version&other_business_parameters&sign_type=hmac&sign=

第二种

GET openapi.x.com/api/name/and/version?other_business_parameters HTTP/1.1
Host openapi.x.com
X-$公司名缩写-AUTHTYPE: HMAC-SHA256
X-$-Client-ID: xxx
X-$-Sign: xxxxxxxxx

无论那种，到网关，最终都 http.reveserve( http://backend-server-name-in-k8s:port)

就从表意、管理、规范、使用等等等等各方面来综合定一个方案，哪种更好。

尝试第一种，使用 apisix ， 配置了一堆 /gatweay.do 的路由。。后台页面像这样：

路由	对应服务
/gateawy.do	s1
/gateway.do	s2
/gateway.do	s3
/gateway.do	s4

第二种，后台页面像这样：

路由	对应服务
/v1/s1/**	s1
/v1/s2/**	s2
/v1/special/**	s3
/v1/444/**	s4

不说技术实现，自己开发的话，无论哪种方案都能实现也都好实现。就说管理、规范等等等等其他方案。

[cloverstd]

如果你有前端监控，第二种方案，前端监控还要适配才能采集到正确的请求 API ，一般情况下前端监控不会处理 request header

我更倾向于把 appid 和 method 放到 path 里，这样中间链路的现有监控都能复用现成的，改造量最小，因为 http 监控打点都会去打点 URL ，但是 header 和 querystring 就不一定了

[blackshadow]

我们用了第二种，更简洁明了。 基于 gateway 的话，配置也方便

[coreki]

我用的第二种。不过第一种在前段定义 api url 的时候是不是更省事？