在本文中，我们将一起对比 rest、graphql 和 grpc 的特性和用法。
rest——最流行的技术
rest
representational state transfer (rest) 是现代 web 开发中最流行的 api 开发技术。它是一个无状态的数据传输架构。客户端请求时会包含该请求所需的所有详细信息，但是服务器不保留客户端的状态。
rest api 支持 http 原生缓存 header 并使用 http 方法（post、get、put、patch 和 delete）来操作数据。因为 rest 的学习门槛较低，所以大家都能轻松使用 rest。
rest 易于扩展且可靠，如果我们还在犹豫不决时，可以优先选择它。
rest的好处可以放心地使用标准 http 方法实现 crud 操作。rest 已经很成熟，有完善的文档，上手简单。支持缓存。友好的可扩展性，并提供客户端和服务器之间的分离。可以轻松地将其集成到应用程序中。rest的缺点存在过度获取和获取不足的问题。当api返回比实际需要的数据更多时，就会发生过度获取。这可能会导致不必要的网络流量、较慢的性能和额外的带宽使用。获取不足发生在api没有返回特定用例所需的所有必要数据时，需要多个请求才能检索所有所需信息。这也可能导致较慢的性能和增加的网络流量，以及更复杂的代码库。不能维持状态。相对来说比较大的 payload。随着应用程序的扩展，端点的数量急剧增加。不容易更新数据库模式或数据结构。何时选择 rest如果没有特定要求，rest 是最佳选择。如果是开发新手，那么使用 rest 是完美的选择，因为它的学习曲线较浅。此外，它还拥有庞大的生态系统，你可以轻松找到问题的解决方案。
在处理较大的请求量和带宽有限时最好使用 rest，因为可以使用它的缓存支持来提高性能。
总的来说，如果你的应用程序没有明确需要使用 graphql 或 grpc，那么就可以使用 rest。
graphql——客户端驱动的标准
graphql 是 2015 年推出的一种数据查询语言，支持开发人员精确定位和获取他们需要的数据。与 rest 相比，graphql 是一种客户端驱动的方法，客户端可以决定需要什么数据、如何获取数据和格式。它还解决了过度获取和获取不足的问题，因为客户端可以明确指定所需的数据。
graphql 使用查询、变更和订阅来操作数据。
查询：从服务器请求数据。变更：修改服务器端数据。订阅：在数据更新时，通过订阅获得实时更新的数据。github 是使用 graphql 的最大公司之一。它在 2016 年从 rest 转向 graphql，极大地帮助了 github 的快速增长。
graphql 的好处非常灵活，可以准确地满足客户的需求。没有过度获取和获取不足的问题。主流语言支持，包括 javascript、java、python、ruby 和 php。允许自定义数据的结构。单个查询可以包含来自多个资源的字段。graphql 的缺点查询可能很复杂。缺乏内置的缓存支持。与 rest 相比，学习 graphql 更具挑战性。默认不支持文件上传。何时选择 graphql当查询包含数据库的许多记录时，graphql 是最佳选择。你可以使用 graphql 消除过度获取，并仅查询必要数据以提高应用程序性能。此外，graphql 非常适合需要从多个资源聚合数据的情况。
当你还不完全了解客户端使用 api 的原理时，也可以使用 graphql。使用 graphql 时，你无需预先定义严格的协议，可以根据客户反馈逐步构建 api。
grpc——一种以性能为导向的技术
grpc 是 google 于 2016 年推出的远程过程调用的进化版本。它是一种轻量级解决方案，使用最少的资源提供最大的性能。
grpc 遵循基于协议的通信方法。它要求客户端和服务器在开始通信之前都有协议。grpc 使用 protobuf（一种声明性语言）创建协议，并使用选定的语言为客户端和服务器生成兼容的代码。
grpc支持的通信方式有4种：
unary ：客户端发送一个请求并等待单个响应。server streaming ：客户端发送一个请求并接收多个响应。client streaming ：客户端发送多个请求并等待单个响应。bidirectional streaming ：客户端发送多个请求并接收多个响应。grpc 的好处开源。开发人员可以根据需要对其进行修改。支持多种语言，包括 javascript、java、c、c++、c#、kotlin、python、go 和 php。能够进行负载均衡。与 rest api 相比，它默认使用 http2 来减少延迟。使用二进制格式序列化数据。支持全双工流媒体。grpc 的缺点学习曲线较陡峭：与传统的rest api相比，grpc需要掌握新的概念和技术，例如protocol buffers和流。可读性差：由于使用二进制编码，grpc的消息不像json或xml那样易于人类阅读和理解。难以调试：由于消息是二进制编码的，调试grpc服务可能比调试rest api更加困难。不适合小型应用：对于只有少量服务和少量数据的小型应用程序来说，grpc可能过于复杂，增加了不必要的开销。不支持web浏览器：由于grpc使用http/2协议，而web浏览器目前还不支持http/2协议的所有功能，因此不能在web浏览器中使用grpc。何时选择 grpc需要高效的数据传输：由于grpc使用二进制协议，因此比json和xml等文本协议更快、更轻量级。需要高可靠性：grpc的基于http/2协议的传输层提供了许多功能，例如流控制、连接复用和头部压缩等，这些功能可以提高可靠性和性能。需要高效的多语言通信：grpc支持多种编程语言，并提供了自动生成代码的工具，因此不需要手动编写跨语言的代码。需要支持多种请求和响应类型：grpc支持四种类型的通信方式（unary、server streaming、client streaming和bidirectional streaming），因此可以选择最适合特定用例的通信方式。需要更好的api管理：grpc提供了强大的api管理工具，例如grpc-gateway和envoy等，这些工具可以提高api的可发现性、文档化和测试。grpc 可以用在微服务架构中来处理服务之间的通信，因为它可以与用不同语言编写的服务进行通信。
结论选择rest、graphql和grpc取决于你的具体场景和需求，基本原则总结如下：
rest：rest适合简单的api和web服务，例如传统的crud操作。它通常更易于理解和使用，并且具有广泛的支持和工具生态系统。graphql：graphql适合需要灵活性和高级查询功能的应用程序。如果你的应用程序需要从多个资源聚合数据，或者需要更好地控制数据的格式和粒度，则graphql是一个不错的选择。grpc：grpc适合需要高效和可靠数据传输的应用程序。如果你需要在多种编程语言之间进行高效通信，并且希望提供更高的性能和可靠性，则grpc是一个不错的选择。不过，rest、graphql和grpc并不是相互排斥的选择。在实际情况下，你可以结合使用，以满足具体需求和场景。
以上就是技术选型：如何选择rest、graphql 和 grpc的详细内容。