GraphQL在标准REST API技术上获得发展的原因。
正如我之前所写， GraphQL是下一代API技术，它正在改变客户端应用程序与后端系统的通信方式以及后端系统的设计方式。
由于从创建它的组织Facebook开始获得支持，并得到其他技术巨头（如Github，Twitter和AirBnB）的支持，因此GraphQL作为应用程序系统的关键技术的地位似乎是可靠的； 无论现在还是将来。
GraphQL的崛起移动应用程序性能和组织敏捷性重要性的提高为GraphQL登上现代企业体系结构的顶端提供了帮助。
鉴于REST是一种非常流行的体系结构样式，它已经允许进行数据交互的机制，与REST相比，这项新技术具有哪些优势？GraphQL中的“QL”代表查询语言，这是一个很好的起点。
借助GraphQL，组织内的不同客户端应用程序可以轻松地仅查询所需的数据，从而取代了其它REST方法，并提高了实际应用程序的性能。使用传统的RESTAPI端点，客户端应用程序可以查询服务器资源，并接收包含与请求匹配的所有数据的响应。如果来自RESTAPI端点的成功响应返回35个字段，则客户端应用程序将接收35个字段
提取问题传统上，REST API无法为客户端应用程序提供唯一的方法来仅检索或更新他们关心的数据。通常将其描述为“过度获取”问题。随着移动应用在人们的日常生活中的普遍使用，过度获取问题产生了现实世界的不良影响。移动应用程序需要发出的每个请求，它必须发送和接收的每个字节，对最终用户的性能造成的负面影响越来越大。数据连接速度较慢的用户尤其会受到次优API设计选择的影响。使用移动应用程序时性能较差的客户更有可能不购买产品和使用服务。低效的API设计会让公司损失金钱。
并非只有“过度获取”，相应的，“欠获取”也是存在的。缺省情况下，只返回客户端实际需要的部分数据的端点需要客户端进行额外的调用以满足其数据需求——这需要额外的HTTP请求。由于过度获取和过度获取问题及其对客户机应用程序性能的影响，一种有助于高效获取的API技术有可能在市场上引起轰动——而GraphQL大胆地跳入并填补了这一空白。
REST的响应REST API设计人员不愿无休止地失败，他们尝试通过以下几种方式来解决移动应用程序性能问题：
“include”和“exclude”查询参数，允许客户端应用程序通过潜在的长查询格式指定他们想要的字段。“复合”服务以使客户端应用程序发出的请求数量和接收的数据效率更高的方式组合了多个端点。虽然这些模式是REST API社区为解决移动客户端所面临的挑战而做出的尝试，但它们在一些关键方面没有实现，即：包含和排除查询键/值对很快变得混乱，特别是对于需要嵌套点表示法语法（或类似语法）以将数据包含和排除为目标的更深的对象图而言。此外，在此模型中调试查询字符串的问题通常需要手动分解URL。
包含和排除查询的服务器实现通常是自定义的，因为基于服务器的应用程序没有标准的方式来处理包含和排除查询的使用，就像没有定义包含和排除查询的标准方式一样。复合服务的兴起创建了更加紧密耦合的后端和前端系统，需要加强协调以交付项目，并将敏捷项目一旦转为瀑布式。这种协调和耦合具有降低组织敏捷性的副作用。此外，复合服务按照定义来的，而不是RESTful风格的。GraphQL的起源对于Facebook来说，GraphQL的诞生是对2011-2012年基于html5版本的旗舰移动应用的痛点和经验的回应。认识到改进性能是最重要的，Facebook的工程师们意识到他们需要一个新的API设计来确保最佳性能。考虑到REST的上述限制，以及需要支持许多API客户端的不同需求，人们可能会开始理解，是什么促使当时的Facebook员工——联合创建者 Lee Byron 和 Dan Schaeffer——创建了后来被称为GraphQL的东西。
通过单一的GraphQL端点和GraphQL查询语言，客户端应用程序能够大大减少需要进行的网络调用的数量，并确保它们只检索需要的数据。在许多方面，这又回到了早期的web编程模式，客户端应用程序代码将直接查询后端系统——例如，有些人可能记得10-15年前在jsp上使用JSTL编写SQL查询！
现在最大的区别在于GraphQL，我们有一个规范可以在各种客户端和服务器语言以及库中实现。 借助GraphQL作为一种API技术，我们通过引入中间的GraphQL应用程序层来分离后端和前端应用程序系统，该层提供了一种以与组织的业务领域相一致的方式访问组织数据的机制。
除了解决软件工程团队遇到的技术挑战之外，GraphQL还促进了组织敏捷性的提高，特别是在企业中。 引入GraphQL的组织敏捷性增加通常归因于以下因素：
GraphQL API设计人员和开发人员无需在客户端需要一个或多个新字段时创建新的端点，而是能够将这些字段包含在现有的图形实现中，从而以较少的开发工作量和跨应用程序系统的较少更改的方式公开新功能。通过鼓励API设计团队将更多的精力放在定义对象图上，而不是在专注于客户端应用程序所交付的内容上，前端和后端软件团队为客户提供解决方案的速度日益脱节。注意事项尽管GraphQL具有引人注目的优势，但GraphQL仍然面临着实施挑战。一些示例包括：
围绕REST API的缓存机制更加成熟。
用于使用REST构建API的模式已经非常完善。
尽管工程师可能更喜欢GraphQL等新技术，但与GraphQL相比，市场上基于REST构建解决方案的人才更广泛。
结论通过同时提高性能和组织敏捷性，GraphQL在公司中的采用在过去几年中猛增。但是，与RESTful API设计生态系统相比，它确实有一些成熟的工作。
Graphql最大的好处之一是它不是被设计为替代API解决方案的批发替代品。相反，可以实现GraphQL来补充或增强现有的API。因此，我们鼓励企业逐步采用GraphQL，因为它对应用程序性能和组织敏捷性有最大的积极影响。