Skip to content

graphql-vs-rest.md

Latest commit

 

History

History
119 lines (88 loc) · 6.7 KB

graphql-vs-rest.md

File metadata and controls

119 lines (88 loc) · 6.7 KB

GraphQL vs. REST：为你的现代应用选择正确的API架构

引言：API架构的十字路口

在现代应用开发中，API（应用程序编程接口）是连接前端客户端（如Web浏览器、移动应用）与后端服务器的桥梁。多年来，REST (Representational State Transfer) 以其简单、直观的特性，成为了构建Web API的事实标准。

然而，随着应用日益复杂、客户端种类增多（Web、iOS、Android、IoT设备等），REST架构的一些固有弊端开始显现。为了解决这些问题，Facebook于2015年推出了一个全新的API查询语言和运行时——GraphQL。

GraphQL并非要完全取代REST，而是为特定的问题场景提供了一个更强大、更灵活的解决方案。那么，它们的核心区别是什么？你又该如何为你的下一个项目选择合适的架构呢？

REST：以资源为中心的经典范式

REST是一种架构风格，它将服务器上的所有东西都看作是 资源（Resource）。每个资源都有一个唯一的URL（或称 端点，Endpoint）来标识。客户端通过标准的HTTP方法（Verbs）与这些端点交互，来对资源进行操作。

  • GET /users/1：获取ID为1的用户信息。
  • POST /users：创建一个新用户。
  • PUT /users/1：更新ID为1的用户的完整信息。
  • DELETE /users/1：删除ID为1的用户。

REST的痛点

尽管简单直观，但REST在处理复杂应用时常常会遇到两个主要问题：

  1. 过度获取 (Over-fetching)：

    • 问题：服务器定义的端点返回了固定的数据结构，其中可能包含了客户端并不需要的信息。
    • 例子：一个手机App的首页可能只需要展示用户的头像和昵称，但 GET /users/1 端点却返回了包括用户地址、注册时间、邮箱在内的所有信息。这浪费了宝贵的网络带宽和客户端处理资源。

  2. 请求不足 (Under-fetching)：

    • 问题：客户端需要的数据分散在多个资源端点上，导致需要发起多次HTTP请求才能获取所有需要的信息。
    • 例子：要显示一个用户的帖子列表及其评论，客户端可能需要先请求 GET /users/1/posts 获取帖子列表，然后对每个帖子ID再分别请求 GET /posts/123/comments。这种“N+1”请求问题会显著增加应用延迟。

GraphQL：以查询为中心的灵活新贵

GraphQL从根本上改变了客户端与服务器的交互方式。它不再有众多的端点，而是通常只提供 一个统一的端点（如 /graphql）。客户端通过向这个端点发送一个 查询（Query） 来精确地描述自己需要什么数据。

GraphQL的核心概念

  1. 强类型模式 (Strongly-Typed Schema)：

    • GraphQL API的核心是一个在后端定义的 模式（Schema）。这个模式使用GraphQL的模式定义语言（SDL）来描述API中所有可查询的数据类型及其关系。它就像一份API的“合同”，客户端和服务器都必须遵守。

  2. 客户端驱动的查询：

    • 客户端可以构建一个与所需数据结构完全相同的查询。不多不少，服务器就返回与查询结构完全匹配的数据。
    # GraphQL 查询
query GetUserWithPosts {
  user(id: "1") {
    name
    avatarUrl
    posts(last: 3) {
      title
      createdAt
    }
  }
}
    // 对应的JSON响应
{
  "data": {
    "user": {
      "name": "Alice",
      "avatarUrl": "https://example.com/avatar.jpg",
      "posts": [
        { "title": "My First Post", "createdAt": "2024-01-01" },
        { "title": "Learning GraphQL", "createdAt": "2024-02-15" },
        { "title": "Hello World", "createdAt": "2024-03-20" }
      ]
    }
  }
}
    • 这个例子完美地解决了REST的痛点：客户端只请求了name, avatarUrl和最近3个帖子的title和createdAt，服务器也只返回了这些数据，一次请求就完成了所有操作。

核心差异对决

特性 REST GraphQL
数据获取 多个端点，每个资源一个URL 单一端点，通过查询获取数据
数据形状 服务器决定响应结构 客户端决定响应结构
网络请求 可能需要多次请求（Under-fetching） 通常一次请求即可获取所有关联数据
数据负载 容易返回过多无用数据（Over-fetching） 精确获取所需数据，无冗余
模式/类型 无内置标准，依赖OpenAPI/Swagger等外部工具 强类型，Schema是核心，自带文档和校验
HTTP缓存 简单直接，利用标准HTTP缓存机制 更复杂，因为大多请求都是POST到单一端点
错误处理 依赖HTTP状态码（如404, 500） 通常所有请求都返回200，具体错误信息在响应体的errors字段中
学习曲线 相对平缓，基于已有的HTTP知识 较陡峭，需要学习新的查询语言、类型系统和生态工具

如何选择：没有银弹，只有取舍

选择 REST，如果...

  • 你的应用非常 简单、资源驱动，比如一个简单的CRUD后台管理系统。
  • HTTP缓存 对你的应用性能至关重要。
  • 你的团队对RESTful API和相关工具链非常熟悉，希望快速启动项目。
  • API的消费者比较单一，数据需求固定。

选择 GraphQL，如果...

  • 你的应用有 多种不同类型的客户端（如Web、iOS、Android），它们对数据的需求各不相同。
  • 前端需要展示 复杂、嵌套的数据，希望减少API请求次数，提升用户体验。
  • 你希望 前后端能够并行开发。一旦Schema定义好，前后端就可以基于这份“合同”独立工作。
  • 你希望API自带强大的 自省（Introspection）和文档 功能，提升开发效率。

结论

GraphQL和REST并非敌人，而是解决不同问题的两种工具。

  • REST 是一种成熟、简单、可靠的架构风格，非常适合构建资源明确、关系简单的API。
  • GraphQL 则是一种强大、灵活的查询语言，赋予了客户端前所未有的能力，特别适合处理复杂的数据关系和多变的客户端需求。

在现代架构中，两者甚至可以共存。例如，在一个微服务架构中，不同的服务可以通过REST进行内部通信，而对外则提供一个统一的GraphQL网关，来聚合这些内部服务，为外部客户端提供最佳的调用体验。理解它们各自的优劣，并根据你的具体业务场景做出明-

  • 智的选择，是通往成功API设计的关键。