REST、GraphQL与gRPC的比较 - danhacks


REST,GraphQL和gRPC是客户端-服务器和服务器到服务器通信的3种流行形式。选择可能很困难,因此本简要指南可以提供帮助。在每个部分中,将提供一个示例来说明检索用户。
 
REST

  • 描述数据的HTTP路径,例如/ users作为用户的集合
  • 容易发现的数据(例如,用户ID 3位于/ users/3,路径下可执行CRUD操作
  • HTTP中的CRUD操作对应REST操作:用于创建的POST / PUT,用于读取的GET,用于更新的POST / PUT和用于删除的DELETE
    • 路径中带有ID的POST表示更新现有实体,没有ID的POST表示创建
    • 带有ID的PUT意味着创建一个实体并覆盖该实体(如果已有的话)

优点
  • 简单易学
  • 广泛使用,大多数工程师对此很熟悉
  • 使用常见的HTTP动词,在RFC 2616中有很好的描述
  • 使用Chrome开发人员工具或Wireshark可以轻松拦截调试信息,无需其他特殊工具即可轻松读取有效负载

缺点
  • 效率低下。必须为每个用例重写API,以防止获取过多或不足
  • JSON对象很大,字段名称是重复的

 
GraphQL
  • 使用POST进行所有操作,并使用单个HTTP路径,例如/ graphql
  • 两种操作类型是“查询”和“变异”,它们在JSON请求正文中指定
    • 查询用于读取数据
    • 变异用于创建,更新和删除数据
  • 从客户端传递到服务器的查询声明了HTTP请求所请求的字段
  • 解析程序在服务器上实现,用于返回特定字段的值
  • 数据结构是在GraphQL模式中预定义的

优点
  • 解决困扰REST和gRPC的上下获取问题
  • 仅发送调用者在查询中请求的响应中的字段

缺点
  • 错误会出现在状态为200的响应主体中,如果库不包含错误,则会导致更复杂的客户端逻辑来解析错误
  • 默认情况下使用大的JSON对象,并且字段名称是重复的

 
gRPC
  • 适合微服务架构
  • 通常从Protobuf对象生成
  • 在Protobuf中声明服务,并在服务器代码中实现
  • 客户端库是从Protobuf代码为每种语言生成的

优点
  • Polyglot:生成代码以调用最流行的编程语言的服务
  • 默认情况下使用Protobuf进行运输以提高效率
  • 自动解决重试,网络问题等
  • 用您的编程语言生成客户端和服务器代码。这样可以节省编写服务调用代码的工程时间

缺点
  • Protobuf难以通过导线进行拦截并解析为人类可读的格式
  • 必须为每个用例重写API,以防止获取过多或不足