Should the HTTP Gateway be more flexible?

[hide-in-code]

go-zero/gateway/server.go

Line 221 in aeceb3c

Method: strings.ToUpper(m.Method),

The code here determines that go-zero's gateway can only proxy through the Mappings set in etc/gateway.yaml, including request paths and request methods. In actual production, the number of backend service APIs continues to increase rapidly, and the request methods of backend interfaces are constantly changing. As such, when using go-zero as an HTTP gateway, this complex and cumbersome configuration will be a terrible experience. I'm wondering if the official team has more improvement plans to simplify the configuration for this part.

I hope the community can consider this request and create an HTTP gateway service that is more in line with go-zero's style and has excellent performance. Thank you.

---

go-zero/gateway/server.go

Line 221 in aeceb3c

Method: strings.ToUpper(m.Method),

这里的代码决定了go-zero的网关仅仅能通过etc/gateway.yaml中设定的Mappings进行proxy，包括请求的路径和请求方式，而实际生产中，后端服务的api个数一直在处于激增的情况，包括后端接口的请求方式也是千变万化，如此，在使用go-zero作为HTTP网关的时候，这种复杂繁琐的配置将会是一种糟糕的体验，不知道官方对于这部分内容是否有更多对于配置简化的改进计划。

希望社区可以考虑下这块诉求，并创造出更具备go-zero风格和性能优异的http网关服务，感谢

[hide-in-code]

go-zero/gateway/server.go

Line 275 in aeceb3c

u.Path, err = url.JoinPath(target.Prefix, u.Path)

To add more information, the prefix here will be appended to the downstream backend service, which seems to only serve to reduce the configuration operations of mappings. However, in practice, developers may prefer to use the prefix to distinguish backend microservice proxies (my habit comes from using Java Spring Boot gateways). I hope the community will also consider this request.

---

go-zero/gateway/server.go

Line 275 in aeceb3c

u.Path, err = url.JoinPath(target.Prefix, u.Path)

再补充一下，这里的prefix会拼接到下游的后端服务中，作用看起来仅仅是减少mappings的配置操作，而实际情况下，开发者可能更倾向于通过prefix来区分后端的微服务代理(我的习惯来自于java spring boot的网关使用)，希望社区也一并考虑这一块诉求