GraphQL和REST都是构建API的方法，在它们之间的选择是后端工程中最常见的架构决策之一。这场争论产生的热量往往多于光明，因为两种方法都解决了真实问题——关键是理解每种方法解决哪些问题，以及针对哪些工作负载。
REST：默认选择及其原因
REST（表现层状态转换）是一种架构风格，而不是协议——它使用HTTP方法（GET、POST、PUT、PATCH、DELETE）和URL作为主要接口。核心原则：无状态（每个请求包含所需的所有信息——没有服务器端会话状态）；面向资源（URL代表资源——/users/123, /articles/456/comments）；统一接口（标准HTTP方法与标准语义）。为什么REST是大多数API的默认选择：它与HTTP缓存自然配合（带Cache-Control标头的GET请求——CDN本机理解REST）；它实现简单，消费也简单（每个HTTP客户端都有效）；它易于调试（打开浏览器，或使用curl）；它与每个现有的工具链、防火墙、代理和基础设施组件一起工作；这些概念（资源、动词、状态码）普遍被理解。REST的问题：过度获取——GET /users/123返回完整的用户对象，即使你只需要名字；获取不足——要渲染带有作者和评论的博客文章，你可能需要3个单独的API调用（/posts/1, /users/1, /posts/1/comments）；API表面随产品要求演变——为一个客户端添加一个字段不会破坏任何东西，但会使API对其他人变得杂乱；版本控制很尴尬（URL或标头中的v1、v2、v3——两种方法都很混乱）。REST适用于：简单性和缓存重要的公共API；内部通信的微服务，其中请求/响应形状稳定；webhook端点；文件上传/下载；流式传输。
GraphQL：它实际解决什么
GraphQL（由Facebook/Meta开发，2015年开源）是API的查询语言和执行这些查询的运行时。关键见解：客户端精确指定需要什么数据，而不是服务器定义响应形状。一个单一端点（通常是/graphql）接受所有查询和变更。GraphQL解决什么：过度获取和获取不足——客户端精确指定需要哪些字段，并恰好获得那些，不多不少；在一个请求中获取多个资源——单个GraphQL查询可以在一次往返中检索用户、他们的文章以及每篇文章的评论（模式解析所有关系）；模式优先开发——API由强类型模式描述，同时作为文档和合同；内省——GraphQL API是自文档化的；客户端可以查询模式以发现可用的类型和字段。GraphQL擅长的地方：带宽重要且需要准确字段来渲染特定视图的移动客户端；多个客户端（iOS、Android、Web）对相同底层数据有不同数据要求的产品API；快速演化的产品API，其中客户端不应在服务器添加字段时被迫更新；前端和后端独立迭代的团队。GraphQL的问题：缓存更难（具有相同URL但不同查询体的POST请求——HTTP缓存不起作用；解决方案：持久化查询、Apollo或Relay的标准化客户端缓存）；N+1查询问题（解析用户列表及其文章可能进行1+N个数据库查询——需要DataLoader或等效批处理）；运营复杂性（模式管理、工具、安全——防止滥用的查询深度/复杂度限制）；实现者和消费者的学习曲线。GraphQL通常不值得用于：具有稳定响应形状的简单API；模式管理开销超过收益的团队；HTTP缓存至关重要的系统；客户端复杂且可以处理版本控制的B2B API。
