本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 比较 REST 和 GraphQL
<a name="comparing-rest-graphql"></a>

APIs （应用程序编程接口）在促进应用程序之间的数据交换方面起着至关重要的作用。如前所述，出现 APIs 了两种突出的设计方法：GraphQL和REST。虽然两者的基本目的都是实现客户端-服务器通信，但它们的实施和使用案例有很大不同。

GraphQL 和 REST 有几个共同的关键特征：

1. **客户端-服务器模型**：两者都使用客户端-服务器架构进行数据交换。

1. **无状态**：两者都不会在两次请求之间保留客户端会话信息。

1. **基于 HTTP**：两者通常都使用 HTTP 作为底层通信协议。

1. **以资源为导向的设计**：两者都围绕资源来设计数据交换，资源是指客户端可通过 API 访问和操作的任何数据或对象。

1. **数据格式灵活性**：JSON 是两者中最常用的数据交换格式，但也支持 XML 和 HTML 等其他格式。

1. **与语言和数据库无关**：两者都可以使用任何编程语言或数据库结构，因此具有很高的互操作性。

1. **缓存支持**：两者都支持缓存，允许客户端和服务器存储经常访问的数据以提高性能。

GraphQL 和 REST 虽然具有一些共同的基本原则，但在 API 设计和数据获取方法上有很大的不同：

1. **请求结构和数据获取**

   REST 使用不同的 HTTP 方法（GET、POST、PUT、DELETE）对资源执行操作。这通常需要使用多个端点处理不同的资源，从而导致数据检索效率低下。例如，运行 GET 操作来检索用户数据可能会导致数据过度获取或获取不足。为获取正确的数据，可能会调用截断操作或调用多个操作。

   GraphQL 使用单个端点执行所有操作。它依赖查询来获取数据，依赖变更来修改数据。客户端可以使用查询在单个请求中精确获取所需的数据，从而通过更大限度地减少数据传输来减少网络开销。

1. **服务器端架构**

   REST 不需要服务器端架构，但可以选择定义服务器端架构，以实现高效的 API 设计和文档。

   GraphQL 使用强类型服务器端架构来定义数据和数据服务。该架构采用 GraphQL 架构定义语言（SDL）编写，包括每个对象的对象类型和字段，以及为每个字段定义操作的服务器端解析器函数。

1. **版本控制**

   REST 通常在 URL 中包含版本控制，这可能会导致同时维护多个 API 版本。版本控制不是强制性的，但可以帮助防止重大更改。

   GraphQL 要求向后兼容，从而在不进行明确版本控制的情况下促进 API 的持续发展。删除的字段会返回错误消息，而弃用标签会逐步淘汰旧字段并返回警告消息。

1. **错误处理** 

   REST 为弱类型，需要在周围的代码中内置错误处理。这可能无法自动识别与类型相关的错误（例如，将数字解析为文本）。

   相比之下，GraphQL 为强类型，需要全面的架构定义。这使您的服务能够自动识别许多请求错误且详细程度较高。

1. **使用案例**

   REST 更适合：
   + 数据要求不那么复杂的较小应用程序。
   + 所有客户端以类似方式使用数据和操作的场景。
   + 没有复杂数据查询需求的应用程序。

   GraphQL 更适合：
   + 带宽有限的场景，其中更大限度减少请求和响应至关重要。
   + 具有多个数据来源的应用程序，需要在单个端点处合并这些数据来源。
   + 客户端请求差异很大并且预计响应结构会有所不同的情况。

   请注意，可以在单个应用程序 APIs 中同时使用 GraphQL 和 REST 来实现不同的功能领域。此外，您无需完全重写即可升级 RESTful API 以包含 GraphQL 功能。有关示例，请参阅[如何为 AWS 数据源构建 GraphQL 解析器](https://aws.amazon.com/graphql/resolvers/)。