GraphQL 与 REST API使用对比
介绍
简单说一下 GraphQL 与 REST API的的对比
文章修改和引用与：https://avocadev.hashnode.dev/graphql-vs-rest-putting-it-to-rest
正文
使用对比
看看下面的示例中的 JSON。这是对SpaceX API的REST调用的摘录，该调用获取所有着陆尝试的列表。用于进行调用的 URL 是：
https://api.spacex.land/rest/landpads
此摘录是从 REST 调用返回的一系列登陆尝试中提取的单个登陆尝试。
{
"attempted_landings": "16",
"details": "SpaceX's first east coast landing pad is Landing Zone 1, where the historic first Falcon 9 landing occurred in December 2015. LC-13 was originally used as a launch pad for early Atlas missiles and rockets from Lockheed Martin. LC-1 was later expanded to include Landing Zone 2 for side booster RTLS Falcon Heavy missions, and it was first used in February 2018 for that purpose.",
"full_name": "Landing Zone 1",
"id": "LZ-1",
"landing_type": "RTLS",
"location": {
"latitude": 28.485833,
"longitude": -80.544444,
"name": "Cape Canaveral",
"region": "Florida"
},
"status": "active",
"successful_landings": "15",
"wikipedia": "https://en.wikipedia.org/wiki/Landing_Zones_1_and_2"
},
......
上述 JSON 中的九个属性是不可变的。作为调用方，您不能告诉 REST API 仅提供full_name和wikipedia数据。无论 REST API 返回一次登陆尝试还是 1000 次登陆尝试，您始终都会获得这 9 个属性。
这是一件大事，如果你能告诉REST只返回你感兴趣的两个数据字段，那么返回的数据集就会小得多。REST 不仅确保大量无趣的数据通过网络传输，而且还位于客户端的内存中。你可能注意到了工作中这种固有的低效率。
如果可以根据您定义的数据结构查询 API 以获取数据，只请求您想要的数据，那不是很好吗？幸运的是，有，而且这种方式不是REST。 它是GraphQL。
请看下面的例子：
这是一个查询，将针对本文之前使用的 SpaceX REST API 发布的相同土地垫数据运行。但这一次，它是针对SpaceX GraphQL API的GraphQL查询，可以在api.spacex.land/graphql上找到。该查询指定它只关心两个字段：full_name和wikipedia。
下面的数据是 GraphQL 查询的结果
{
"data": {
"landpads": [
{
"full_name": "Landing Zone 1",
"wikipedia": "https://en.wikipedia.org/wiki/Landing_Zones_1_and_2"
},
{
"full_name": "Landing Zone 2",
"wikipedia": "https://en.wikipedia.org/wiki/Landing_Zones_1_and_2"
}, .....
仅返回full_name和wikipedia数据。这是开发人员需要的数据，仅此而已。GraphQL 文件的大小为 1.09 KB。
当我们在 SpaceX REST API 中查询土地垫数据时，返回的 JSON 数组大小为 8.18 KB。请记住，REST API 必须始终返回所有字段。GraphQL 的效率是显而易见的。
性能分析
GraphQL 的吸引力源于其效率的提高。RESTful 服务通常是多个服务器查询的结果，经常返回大量与相关信息混合在一起的不可用数据。这些低效率也会影响客户端返回所有请求信息所需的时间。
由于 GraphQL 减少了端点的数量，因此服务可以通过一次调用获取所有必要的数据，并将其格式化为 JSON 以便快速检索。API 服务器可以使用任何协议交换数据，包括 HTTP、HTTPS、WebSockets 和 TCP，因为 GraphQL 与传输层无关。
与 REST 中的多个端点不同，GraphQL 将所有查询发送到单个端点（即 HTTP POST）。GraphQL 模式也是静态的：GraphQL 不涵盖运行时修改或动态类型定义等动态功能，尽管它允许开发人员定义用于验证和检查的模式。
因此，开发人员必须依赖变通方法或自定义服务器实现，这只会增加开发时间和资源消耗。
由于 GraphQL 充当中介来帮助查询从各种数据源接收的数据，因此它已成为 API 构建的标准。通过准确指示需要哪些数据，并赋予客户端比 REST API 更多的控制权，GraphQL 解决了在 RESTful 服务用例中看到的随机数据返回问题。与其他任何事情一样，您应该在正确的场景中使用它，以最少的权衡获得高性能。
现在让我们谈谈这两种 API 设计技术的主要优点和缺点。
以下是 REST 的优点：成熟并经过数十年的验证。处理各种类型的调用并支持各种数据格式，包括纯文本、HTML 和 JSON。客户端和服务器体系结构的解耦为轻松扩展应用程序提供了极大的可扩展性。
以下是 REST 的缺点： 容易获取不足或过度获取数据。获取所需的所有数据需要多次往返请求。没有构建 REST API 的具体标准化方法
以下是 GraphQL 的优点： 强类型系统（表示为模式）的存在大大减少了实现查询所需的工作量。类型系统规定了服务器可以返回的数据结构。适用于避免数据获取不足或过度提取 以及前端和后端的并行 API 开发。
以下是 GraphQL 的缺点：缺乏内置的缓存功能。由于它始终返回 HTTP 状态代码 200，因此无论请求是否成功，这可能会使错误报告和 API 监控复杂化。
结语
总之，熟练的 API 设计者应该承认开发人员将如何使用 API。这不仅会告知哪种设计风格最适合 API 的要求，而且无论选择哪种设计风格，它还会产生出色的 API。
我希望你喜欢和快乐编码！
