选择gRPC-Gateway还是同时维护REST与gRPC服务器？

方案2算不算反模式？ #

完全不算。当REST接口有复杂需求（比如你提到的同时包含multipart-form-data和JSON元数据的请求），或者需要深度适配OpenAPIv3的工具链时，独立维护两套API规范是很务实的选择。

gRPC的设计初衷是面向内部服务的高效通信，而REST往往要对接外部用户或异构系统，两者的API设计理念、场景诉求本身就有差异。分开维护能让REST端完全贴合OpenAPIv3的生态（比如用代码生成、校验、文档工具），gRPC端也能保留自身的性能优势，只要底层业务逻辑完全复用，就不会造成冗余或维护负担的过度增加。很多有类似需求的团队都在这么做，属于常规实践。

行业内gRPC-Gateway的使用现状 #

gRPC-Gateway在内部服务对外暴露标准化REST接口的场景中应用很广泛，比如纯JSON格式的CRUD接口、不需要复杂请求结构的场景。它的核心优势是只维护一套Protobuf定义，自动生成REST网关和OpenAPIv2文档，大幅减少重复工作。

但它的局限性也很明显：

• 对复杂请求格式（如multipart混合数据）支持不足，Protobuf的注解机制很难覆盖这类非标准化的HTTP请求场景；
• 从OpenAPIv2转v3虽然有自动化工具，但转换后的文档通常需要大量手动调整，无法充分利用v3的新特性（比如Components复用、更灵活的安全规则定义），很难满足“完全支持OpenAPIv3”的要求。

针对你的场景的建议 #

既然你已经倾向方案2，且项目明确要求REST端必须适配OpenAPIv3工具链，这个选择是合理的。可以通过以下方式降低维护成本：

• 确保底层业务逻辑完全复用，REST和gRPC的API层只做请求/响应的格式适配；
• 借助工具做部分字段同步，比如从Protobuf生成OpenAPI文档的基础结构，再手动补充REST特有的规则（比如路径参数、请求格式、响应码），减少重复编写；
• 制定内部规范，让两套API的核心业务语义保持一致，避免出现接口行为不一致的问题。

内容的提问来源于stack exchange，提问作者aloha