目录
一、
外卖服务器场景
外面服务器沟通有很多模式——展示商家列表等等,只是其中一个,因此需要一个统一的规划了——不同应用程序,里面的自定义格式是不一样的,这样的设计十分灵活,最好要有一个统一的标准,
显示商家列表,有很多项,每一项包含了一些信息,商家名称,图片,好评率等等,距离你的位置,评分等等
设计:
1.明确当前请求和响应,包含哪些信息(根据需求来)
请求如:用户身份,用户当前位置,商家名称,图片,好评率····
2.明确具体的请求和响应格式
示例:请求1234,80,100\n
明确格式,就是看你按照啥样的方式构造出一字符串,后续这个字符串可根据TCP/UDP的payload进行传输,另一方面服务器可以对这个字符串进行解析,解析出逗号前面的是useld,逗号前面是经纬度···这种
响应:麻辣烫,2,jpg,99%,1.2km,4.8\n,->这个时候构造出一个响应这样的字符串,客户端可按照这样的格式进行解析。
网传的数据,本质是字符串(准确的说二进制“字符串”(更像字节串,⚠️当然没有这种东西,但是可以这么理解)无法直接传输JAVA对象这样的内容,JAVA写代码,都是各种的对象,但是发送数据的时候,就需要把对象转换为(二进制)字符串(叫做序列化),但是收到数据的时候,也会把“二进制”转换成字符串(反序列化)
二、
实际上不管怎么约定都可以,只要保证客户端和服务器遵守一个原则就好
示例:
三、
然后有一些牛逼哥:搞出一些通用的格式,可以参考
1.XML:以成对为标签,来表示键值对信息,同时标签支持嵌套,就可以构成一些更复杂的树型结构数据
请求:
. ->(结束标签) 1234 <-(表示的是键值对结构,key:userId,value:1234) 100*80 (对象,本质上是键值对,属性名字是键,属性的值就是值)XML:很像我们之前写的html5(省略吧),里面的标签都是程序员自己定义的
优点:XML非常清晰的把结构化数据表示出来了
缺点:表示数据需要引入大量标签,看起来繁琐,同时也会占用不少带宽<-(国内最贵)
2.json(主流)
本质也是键值对,看起来比xml干净
请求:{ userId:1234 position:"100 80" } (json中,用{}表示键值对,表示【】数组,数组中有个元素,可以是数字,可以是字符串,还可以其他的{},或者【】 响应{ name:"凉皮", image:'1.jpg', distance:'1km', rate:96%, star:4.7 }
也是键值对,当前最主流的格式,未来会常用,json对换行不敏感,假如这些内容放在同一行,也完全合法,一般网络传输的时候,会对json压缩(去掉不必要的换行,空格)会把所有数据放到同一行去,整体占用的带宽更降低了(影响可读性),有很多现成的json格式化工具(“一键还原成可读性的”)
优势:相比于xml,表示的数据简洁很多,可读性非常好的,方便程序员观察中间结果,方便调试问题。
劣势:终究花费一定的带宽来传输key的名字的
3.protobuffer:
谷歌提出来的一套,二进制的数据序列化方式,使用二进制的方式,约定某几个字节表示哪个属性···,最大程度的节省空间(不必传输key,根据位置和长度,区分每个属性的)
优点:节省带宽,最大化效率
缺点:二进制数据,无法肉眼观察,不方便调试,使用起来比较复杂,需要专门编写一个proto文件,描述数据的格式是咋样的->再进一步通过人家提供的工具,把proto文件转换成一些代码,再嵌入到程序中使用的(这个主要用于,对于性能要求更高的环境,属于是牺牲开发效率,换来“运行效率”)
写代码模块:
开发效率>运行效率(一般情况下)
开发效率:程序员写代码的速度
运行效率:软件跑的快不快。
开发效率,要是想提高就找程序员们->(开发中:人力成本,程序猿们的工资,相比一个买的更高级硬件,肯定是开发效率更重要,人力成本更好,当然你要是计算火箭那种需要速度的,要求时间更短,这是c++主场,请远离java,人工智能这东西的底层就是c++)