企业官网建设流程全解析

现货做网站,广告创意设计说明,网站为什么需要备案号,深圳公司官网设计Rest、GraphQL、gRPC#xff0c;是目前对Web暴露API常用的三种组织方式。每当看着这些名词#xff0c;我都会进入选择困难症。这些丰富多彩的协议填满了我们的工具箱#xff0c;同时也抛出了一个难题#xff1a;如果我想要自己的程序健康长久#xff0c;就不得不了解它们到…Rest、GraphQL、gRPC是目前对Web暴露API常用的三种组织方式。每当看着这些名词我都会进入选择困难症。这些丰富多彩的协议填满了我们的工具箱同时也抛出了一个难题如果我想要自己的程序健康长久就不得不了解它们到底是什么东西。这很让人讨厌因为它们就像是螺丝螺母的型号你做的工作只不过是从一堆零件里挑合适的出来让它们配对并让它们组合成你想要的功能。很无趣也非常没有价值。但看在钱的面子上又不得不学。本文就是让你快速进行选择不拖泥带水赶紧完成工作喝杯茶也比瞎纠结有趣的多。RestRest是最常用的API交互手段SpringBoot对其进行了高度的集成。它通过语义化的URL使用最通用的HTTP协议完成无状态的请求交互。Rest是Restfull的简称使用HTTP的POST、GET、 PUT、 PATCH 和DELETE来定义对资源的操作。虽然有这么的操作意义但在平常的使用中我们习惯只使用它的POST和GET方法对应在Spring里就是GetMapping和PostMapping注解。没别的原因只因为Rest看似很强大但在企业开发中曲线相对较高很多聚合资源和复杂的操作根本无法抽象成资源。但Rest变种也算Rest它依然是使用最广泛的模式。选择Rest的原因是因为它的生态太好了。从Ruby到Java、从Golang到Rust几乎没有语言不支持Rest。如果你想要开发一个Web系统那几行代码非常容易的就能把你的API暴露出去。而且它与网关的集成度非常高各种负载均衡组件对HTTP的协议可以说是炉火纯青如果你选择它的话真的是非常的省事。但是Rest也意味着效率低下。由于它要兼容HTTP1.0频繁的短链接也造成了资源的浪费。即使是长链接HTTP臃肿的体积也让它在追求高性能的场景中稍逊一筹。加上它是无状态的如果你想传递一些伴随着用户的数据比如JWT Token那么你不得不放在HTTP Header或者Cookie中这加重了整体的传输负担。总之Rest是一个快速的开始但在高性能、有状态的场景下你不得不选择其他。gRPCgRPC当然是Google的作品因为它传输的数据就是google另外一个产品protobuf所编码的。提到gRPC就不得不提到thrift它们是一样的东西。但由于google的光环gRPC更加流行。gRPC的开发就不像Rest那么灵活它需要你定义一份合同然后在client和server端同时引用和传输它。有了这份合同就可以压缩数据。比如我们常用的json其实冗余信息特别多。如果把json的字段使用固定的int代替或者放在固定的位置进行传递那么字段名称就根本不需要占用那么大的空间。gRPC提供了多种数据传输模式。类似于Rest的HTTP的一问一答模式Client-Streaming 客户端发送数据是流的方式然后以特定信息结尾然后Server返回结果Server-Streaming Client请求了服务端服务端持续发送数据到Client直到通知它结束Bidirectional Streaming 双工通道那就是普通的TCP链接了全部是流的方式gRPC发展了这么多年2016对负载均衡的支持也非常好。相对于传统的Rest它使用HTTP2来传输数据减少了一问一答的等待减少了链接的占用。如果你在搞物联网或者一些弱网环境的数据收集这种高压缩比的数据定然让你事半功倍。当然如果你的微服务体系追求较高的性能结果Rest就占了一半那么gRPC是你的不二选择。当然弱点也是有的。那就是调试的时候不如HTTP的生态全面各种自动化工具缺乏二进制也通常会让人头晕目眩。GraphQLGraphQL也比较年轻到了2015年才诞生它规定了一种只取“所需要”数据的能力。在传统的Rest请求上访问特定的URL你会获得相对固定的结果。不管返回的数据里有多少无用的字段Rest请求都会把请求吐给你。GraphQL的客户端可以决定取出哪些数据甚至是取数据的方式和格式--也就是只取它所需要的数据而不会产生过多的无用数据。Github就是GraphQL的集大成者。在https://docs.github.com/en/graphql上详细的列出了这些接口。下面就是一个典型的带有变量的查询语法。可以看到这使得请求端比如Js有了类似编程的能力。query($number_of_repos:Int!) { viewer { name repositories(last: $number_of_repos) { nodes { name } } } } variables { number_of_repos: 3 }当然它的弱点也是显而易见的。相对于直接请求某个地址这些查询语句使得请求的构造变的复杂学习曲线相对陡峭。对于复杂的资源查询尤其是字段非常多且层次非常深的资源查询GraphQL不失为一种好的方式。End以上就是这三种主要方式的简单介绍。目前Rest毫无疑问是使用最多的原因就是因为简单gRPC有着迅猛的发展势头尤其在微服务领域已经得到广泛应用GraphQL很复杂当然对复杂的业务数据来说是一个好的工具。当你的业务纯粹是功能为主访问量一般那就毫无疑问的使用Rest来快速实现拿钱完事如果你的业务对性能要求很高交互方式上又有流的表现形式那可以选择gRPC这一般发生在项目初期否则还是遵循公司的基础建设为主GraphQL就相对比较高级了引入它很痛周期也较长是否使用它来组织数据就看你的决心了。但无论如何比起绣花针刺大象永远不要使用大炮打蚊子。那可能轰不着蚊子而会炸了自己。