GraphQL与REST触发后端操作的选型及混合API开发实践疑问

1. 动作触发类场景优先选REST #

这类仅触发后端动作、不需要返回结构化数据的场景，优先选择REST实现，核心理由有3点：

• 适配核心需求：这类场景的核心是快速识别操作状态，REST可以直接用标准HTTP状态码表达结果，比如用204 No Content表示操作成功无返回、400 Bad Request表示参数非法、403 Forbidden表示验证链接过期、429 Too Many Requests表示触发限流，客户端、监控、日志系统都可以直接识别状态码做处理，不需要额外解析响应体，比GraphQL必须解析200响应中的errors字段要简洁很多。
• 实现成本更低：这类接口不需要关联数据模型、不需要处理复杂的查询解析逻辑，REST只要写单个路由处理函数即可，比GraphQL需要额外定义Mutation schema、编写Resolver的流程要轻量很多。
• 兼容性更好：比如邮箱验证、密码找回的回调链接是直接从邮件端打开的浏览器原生GET请求，用REST端点可以直接适配，不需要额外开发前端中转页构造GraphQL请求，减少不必要的流程。

如果你的团队已经全栈统一使用GraphQL规范，不想维护两套接口规则，用GraphQL Mutation实现这类逻辑也完全可行，只需要提前约定好errors字段的错误码规范即可，只是综合收益不如REST高。 #

2. 混合GraphQL+REST端点是行业通用的合理实践 #

这种混合方案是非常普遍的行业做法，完全合理：

• 两种技术本身就是互补关系，没有非此即彼的要求：GraphQL的优势是支持客户端自定义返回字段、减少多接口请求开销，适合需要灵活查询的业务CRUD场景；REST的优势是轻量、符合原生HTTP语义，适合动作触发、文件上传下载、第三方Webhook回调这类场景，二者搭配刚好覆盖不同的业务需求。
• 主流厂商的实践均采用混合方案：哪怕是最早推广GraphQL的GitHub、Shopify等厂商，公开API也同时保留了大量REST端点，内部服务更是会根据场景自由选型，不会为了技术栈统一强行要求所有接口都用同一种实现。
• 维护成本极低：当前主流的后端框架都支持同时配置两类路由，只需要团队提前约定好路由前缀区分即可（比如/graphql路径下为GraphQL接口，/api路径下为REST接口），不会出现维护混乱的问题。

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