GraphQL vs REST：API设计范式的深层比较与选型指南
REST API的核心约束是资源（Resource）和HTTP动词（GET/POST/PUT/DELETE）的映射：每个URL代表一个资源，HTTP动词表示操作类型。这一简洁模型使REST容易理解、易于缓存（GET请求天然可缓存）、工具链成熟（curl、Postman、Swagger/OpenAPI均为REST设计）。但REST在某些场景下表现出明显局限。
REST的典型问题
过度获取（Over-fetching）：`GET /users/42`返回包含30个字段的用户对象，但客户端只需要name和avatar。浪费带宽，对移动端影响尤为明显。
获取不足（Under-fetching）：获取用户信息需要依次调用`GET /users/42`、`GET /users/42/posts`、`GET /users/42/followers`——三个HTTP请求，三次网络往返，增加了延迟和复杂性（N+1问题的API版本）。
版本管理：REST API的变更通常需要版本控制（`/v1/`、`/v2/`），维护多版本API带来额外成本。
GraphQL的核心机制
GraphQL只有一个端点（通常是`POST /graphql`），客户端在请求体中声明所需字段：
“`graphql
query {
user(id: 42) {
name
avatar
posts(last: 5) {
title
publishedAt
}
}
}
“`
一次请求返回精确所需的数据。这解决了过度获取和获取不足问题，但引入了新的权衡：N+1查询问题（每个`posts`字段可能触发独立数据库查询）需要通过DataLoader批处理解决；缓存复杂度（POST请求不能被HTTP层缓存，需要应用层缓存策略）；查询复杂度控制（防止恶意深度嵌套查询导致服务器过载）。
选型参考：GitHub、Twitter、Shopify等采用GraphQL暴露其平台API；大量企业内部微服务仍以REST为主。GitHub同时提供REST v3和GraphQL v4两套API供比较，参考我们的API设计最佳实践了解REST设计细节。
