何时使用GraphQL、gRPC 和 REST
在设计应用程序时，开发人员可以从各种客户端-服务器通信协议中进行选择。使用 GraphQL、gRPC 和 REST 在当代项目中相对常见。每种协议都可以提供各种优势，具体取决于您的应用需求。
一.GraphQL 是一种灵活的数据请求方法，它专注于特定请求并仅提供必要的请求。GraphQL 是客户端驱动的，这一事实将其与其他 API 区分开来，而不是以标准方式处理它，由客户端做出所有决策。它的优点是它与语言无关，请求是通过单个终结点发出的，并且是强类型的，因为它具有架构。
GraphQL 的优点和缺点
GraphQL 让开发人员能够专注于他们的查询，只提取他们想要的数据。
虽然这种灵活性对客户端来说是一个好处，但对服务器开发人员来说也是一个缺点。需要有人做繁重的工作，这样服务器性能才能不可预测。请求的完全自定义也意味着缓存非常困难。对于希望采用 GraphQL 方法的 API 开发人员来说，这些困难确实转化为陡峭的学习曲线。
何时使用 GraphQL
如果您预计客户端会以多种方式使用您的数据，那么 GraphQL 可能是一个理想的选择。赋予 API 使用者权力可能意味着在后端做更多的工作，但它可能会使您的 API 更易于使用。假设客户端应用程序需要高度结构化的信息来构建界面或填充应用程序中显示的信息。在这种情况下，GraphQL 可以成为减少您需要向服务器发出的请求数量的好方法。
二. REST是最受欢迎的一种。当一个域可以被描述为一组资源时，它非常适合。REST是一种用于数据传输的无状态架构。REST的一些优点是它是一个成熟的标准，使用简单，并且具有良好的缓存支持。
REST 的优缺点
什么是 RESTful API？它们被广泛使用，大多数应用程序开发人员都熟悉它们。由于 REST 与 HTTP 协议的设计密切相关，因此浏览器和其他 HTTP 客户端将原生理解来自 RESTful API 的响应。
不过，REST并不是万能的，这就是为什么它不是唯一的API架构。RESTful API 可能会导致臃肿的响应，尤其是在资源特别复杂的情况下，这是 GraphQL 日益普及的驱动因素之一。对于功耗非常低的客户端来说，REST 也可能不是一个理想的选择，这就是 gRPC 在这种情况下的吸引力所在。
RESTful API 开发的灵活性也让开发人员承担了遵守原则和标准的责任。虽然 OpenAPI 规范是一个很好的工具，但坚持它必须是一个积极的决定，因为 RESTful API 本质上并不是自文档化的。
POST：创建新资源。
PUT：如果资源存在，则完全更新资源，如果不存在，则创建资源。
DELETE：删除资源。
PATCH：部分更新现有资源。
GET：查询一个或多个现有资源。
何时使用 REST API
如果您没有令人信服的理由选择其他方式，那么 REST 可能是您的应用程序的最佳选择。虽然 GraphQL 或 gRPC 可能适合具有独特需求的用例，但更多时候，您只想使用良好、可靠的 API 方法进行构建。由于 REST API 的学习曲线较浅，拥有庞大的资源生态系统和大量可供学习的公开示例，因此应将 REST API 视为默认选择。
三. gRPC 是一种提供轻量级和快速系统来获取数据的方法。在这里，主要区别在于它如何描述其合同谈判。它依赖于合同;架构不是管理谈判的东西;它是服务器和客户端之间的关系。虽然处理和计算被委托给容纳资源的远程服务器，但大部分都在客户端使用。它的主要优点是它具有轻量级客户端，使用协议缓冲区发送/接收数据时效率很高，并且是开源的。gRPC 是更通用的远程过程调用概念的演变设计。它允许客户端直接调用远程计算机上的方法，就好像该系统是本地的一样。gRPC 利用协议缓冲区（或 Protobufs）来定义类型安全的接口，并将数据序列化为二进制（而不是基于文本的 JSON 或 XML）以进行数据传输。它还利用了 HTTP/2 的速度和效率，它比 HTTP/1 更可靠、更快。
gRPC 的优点和缺点
使用 Protobufs 进行数据序列化，gRPC 提供了一个令人难以置信的轻量级和快速的 API。由于它非常轻量级，因此在客户端可能没有太多计算能力（例如 IoT）时，通常会使用 gRPC。在这些情况下，服务器会执行繁重的工作。gRPC 还提供了一种在用不同语言编写的服务之间进行通信的绝佳方式，因为接口协定的定义与语言无关。这使得 gRPC 的学习曲线（虽然不像 REST 那么浅）是可以容忍的。虽然 gRPC 非常高效，但浏览器并未很好地支持它。通过在沙盒中进行实验来学习也可能很困难。对于经验不足的 API 开发人员来说，HTTP/2 的使用也可能不熟悉。
何时使用 gRPC
如果需要从客户端计算机中榨取每一滴性能，gRPC 可能是一个不错的选择。这就是为什么 gRPC 的一个广泛用例是促进智能设备之间的通信。鉴于其规模、有限的计算资源和实时功能，物联网设备依赖于 gRPC 的性能才能运行。部署管道工具和应用程序监视系统也可以是 gRPC 的出色应用程序。
因此，何时选择这些协议中的每一个：
如果要构建 CRUD 样式的 Web 应用程序，或者使用结构良好的数据，请使用 REST。
如果 API 是私有的，并且与操作有关，请使用 gRPC。此外，如果性能是必不可少的。
如果您是公共 API，需要灵活地自定义请求，并且希望将来自不同来源的数据添加到公共 API 中，请使用 GraphQL。
我们演示了如何在不同的应用层中应用不同的 API 样式:
结论
我们已经看到，没有一种放之四海而皆准的 API 开发方法。微服务允许独立于其他系统对应用程序功能进行抽象、增强和修改。如果系统的一部分需要 gRPC 实现，其他部分可以合理地同时使用 GraphQL API，同时使用 REST 设计公开其他内容。如您所见，这些选择中的每一个都有特定的用途和好处。在这种情况下，没有明确的赢家，所以你应该使用什么——或者更确切地说，你想使用什么——取决于你的目标和策略。
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
微服务架构设计视频直播平台的系统架构演化
微服务与Docker介绍
Docker与CI持续集成/CD
互联网电商购物车架构演变案例
互联网业务场景下消息队列架构
互联网高效研发团队管理演进之一
消息系统架构设计演进
互联网电商搜索架构演化之一
企业信息化与软件工程的迷思
企业项目化管理介绍
软件项目成功之要素
人际沟通风格介绍一
精益IT组织与分享式领导
学习型组织与企业
企业创新文化与等级观念
组织目标与个人目标
初创公司人才招聘与管理
人才公司环境与企业文化
企业文化、团队文化与知识共享
高效能的团队建设
项目管理沟通计划
构建高效的研发与自动化运维
某大型电商云平台实践
互联网数据库架构设计思路
IT基础架构规划方案一(网络系统规划)
餐饮行业解决方案之客户分析流程
餐饮行业解决方案之采购战略制定与实施流程
餐饮行业解决方案之业务设计流程
供应链需求调研CheckList
企业应用之性能实时度量系统演变
如有想了解更多软件设计与架构, 系统IT,企业信息化, 团队管理 资讯，请关注我的微信订阅号：
![MegadotnetMicroMsg_thumb1_thumb1_thu[2]](http://images.cnitblog.com/blog/15172/201503/211054051419485.jpg "MegadotnetMicroMsg_thumb1_thumb1_thu[2]")
作者：Petter Liu
出处：http://www.cnblogs.com/wintersun/
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。
该文章也同时发布在我的独立博客中-Petter Liu Blog。
