GraphQL 是一种用于API的查询语言和运行时环境。

GraphQL是一种用于API的查询语言。
它并不指代任何框架或具体技术，而是针对数据的查询语言规范。

Web版SQL等于GraphQL。

与REST有什么不同？

休息

RESTful API使用URL和方法来表示资源。

RESTful API利用URL和方法来表达资源。

GraphQL

GraphQL是一种由Facebook开发的查询语言和运行时环境，用于API查询和数据操作。它提供了一种灵活且高效的方法，使前端客户端能够精确地请求所需的数据，并减少了多次请求的需求。通过GraphQL，开发人员可以根据其具体需求编写自定义查询，并从服务器获取只包含所需数据的响应。由于其强大的能力和易于使用的特性，GraphQL在现代Web开发中被广泛采用。

只要一个终端点。在HTTP POST的请求正文中明确指明所需的资源。

优点

能够整合资源

由于REST在URL中表示一个资源，所以对于需要多个资源的复杂页面，需要多次发出API请求。

总的来说，经过精心设计的RESTful API需要多次请求，导致性能下降和代码复杂度增加的缺点。

在GraphQL中，只需明确列出所需的资源并发送请求，就可以一次性高效地获取所需的资源。

2. 在中间层发挥作用

作为微服务的网关（中间层）似乎也是一个不错的选择。

通过定义模式，可以获取与GraphQL兼容的数据源。可以直接获取数据库，也可以在内部调用现有的REST API来获取数据。

与REST API不同的地方

资源限制的观点

如果需要对API进行使用限制，REST通常会设置基于次数的限制，例如每小时限制x次的情况很常见。

GraphQL 资源的拉取数量（即负载）由客户端自行决定，因此需要考虑负载计算的方法。

GitHub的GraphQL API v4将可请求的对象数量转化为一个分数并限制在每小时范围内。

现金效率 (Xianjin xiaolv)

由于GraphQL是单一端点，因此像基于URL的缓存机制或CDN的缓存，例如HTTP的Cache-Controll，不能直接使用。

在中文中，不一定需要提供多个选项来重新表达该语句：虽然并非所有层面（服务器、CDN和客户端）都无法使用缓存，但现实中的缓存实现已经在这些层面上准备就绪，所以还是需要实现额外的内容。

错误处理

在REST中，错误以HTTP状态码来表示。

在 GraphQL 中，如果请求成功，则返回状态码200，如果发生错误，则在错误对象中表示。

总结

• 様々なデータソースを扱えるのでGood

• Web版SQLが発行できてイイネ！

• REST API開発でAPIが多すぎてメンテナンスがしんどいということはGraphQLではなくなりそう。

リソース制限やキャッシュ効率、エラーハンドリングの仕方などREST APIとはまた異なるノウハウが必要

听说从现在开始会成为主流，所以我想努力学习掌握。

请查阅网址