在设计新API或评估现有API时，你会遇到三种主要范式：REST、GraphQL和gRPC。它们做出不同的权衡，选择错误的会在整个项目生命周期中产生摩擦。以下是如何选择。
REST（表述性状态转移）
REST是大多数Web应用程序的默认API范式。它使用HTTP方法（GET、POST、PUT、PATCH、DELETE）来操作由URL标识的资源。特点：无状态；面向资源；广泛理解；每种语言都有出色的工具和客户端支持。优势：简单性和通用性——任何HTTP客户端都可以使用REST API；通过HTTP实现出色的缓存；理解良好的模式（资源上的CRUD）；比替代方案更容易实现和调试；与Web浏览器自然配合。弱点：过度获取（单个端点返回所有字段，即使客户端只需要两个）；欠获取（客户端需要多次往返来从多个资源组装数据——N+1问题）；版本控制很痛苦（URL中的v1、v2、v3，或Accept-Version头）；没有内置合同定义（尽管OpenAPI/Swagger填补了这个空白）。何时使用REST：被许多客户端（不同平台、语言、第三方）使用的公共API；简单的CRUD应用程序；HTTP缓存有价值的情况；优先考虑广泛工具支持和入职便利的团队；与外部客户端通信的微服务。
GraphQL
GraphQL是Facebook开发的查询语言和运行时（2015年）。GraphQL不是每个端点返回固定形状的多个端点，而是有一个单一端点，客户端通过该端点精确指定他们需要的数据。优势：解决过度获取（客户端只请求他们需要的字段）；解决欠获取（单个查询可以从多个类型检索嵌套数据）；强类型模式充当合同和文档；在不进行后端更改的情况下在前端上快速迭代非常出色；内置实时订阅。弱点：复杂性——实现GraphQL服务器比REST更难；N+1查询问题移至服务器（DataLoader模式解决了这个问题，但需要明确实现）；HTTP缓存不能自然与基于POST的查询配合使用；没有特定工具（GraphiQL、Altair）很难测试和调试；不适合二进制或流数据。何时使用GraphQL：多个客户端（Web、iOS、Android）有不同数据需求的前端驱动API；实体具有复杂关系的数据图产品；拥有可以吸收实现复杂性的专用API基础设施的团队；快速前端迭代是优先考虑的API；类型化模式合同提供重要价值的情况。
gRPC
gRPC是谷歌的高性能RPC框架（2016年）。它使用Protocol Buffers（protobuf）作为接口定义语言，使用HTTP/2作为传输。特点：通过.proto文件进行强类型合同；支持一元、服务器流、客户端流和双向流；从.proto定义在多种语言中生成客户端和服务器代码。优势：性能——protobuf二进制序列化比JSON小3到10倍；HTTP/2多路复用减少延迟；一流的流支持；在编译时强制执行的强类型合同；对多语言环境非常出色（从一个.proto文件生成Go、Python、Java、Rust中的客户端）。弱点：不可读（二进制协议需要工具进行检查）；浏览器支持差（grpc-web是一种变通方法，但是间接的）；更陡峭的学习曲线；需要proto文件分发和版本控制纪律。何时使用gRPC：性能重要的内部微服务间通信；流式用例（实时数据、事件流）；多种语言共享合同的多语言环境；延迟敏感应用程序；跨服务边界编译时类型安全有价值的情况。经验规则摘要：公共API→REST；前端数据层→GraphQL；内部服务→gRPC。
