网络原理，了解xml, json,protobuffer的特点

外卖服务器场景带入

大佬们通用的规范格式

一、👦

外卖服务器场景

外面服务器沟通有很多模式——展示商家列表等等，只是其中一个，因此需要一个统一的规划了——不同应用程序，里面的自定义格式是不一样的，这样的设计十分灵活，最好要有一个统一的标准，

显示商家列表，有很多项，每一项包含了一些信息，商家名称，图片，好评率等等，距离你的位置，评分等等

设计：

1.明确当前请求和响应，包含哪些信息（根据需求来）

请求如：用户身份，用户当前位置，商家名称，图片，好评率····

2.明确具体的请求和响应格式

示例：请求1234，80，100\n

明确格式，就是看你按照啥样的方式构造出一字符串，后续这个字符串可根据TCP/UDP的payload进行传输，另一方面服务器可以对这个字符串进行解析，解析出逗号前面的是useld,逗号前面是经纬度···这种

响应：麻辣烫，2，jpg,99%,1.2km,4.8\n，->这个时候构造出一个响应这样的字符串，客户端可按照这样的格式进行解析。

网传的数据，本质是字符串（准确的说二进制“字符串”（更像字节串，⚠️当然没有这种东西，但是可以这么理解）无法直接传输JAVA对象这样的内容，JAVA写代码，都是各种的对象，但是发送数据的时候，就需要把对象转换为（二进制）字符串（叫做序列化），但是收到数据的时候，也会把“二进制”转换成字符串（反序列化）

二、👧

实际上不管怎么约定都可以，只要保证客户端和服务器遵守一个原则就好

示例：

三、😾

然后有一些牛逼哥：搞出一些通用的格式，可以参考

1.XML：以成对为标签，来表示键值对信息，同时标签支持嵌套，就可以构成一些更复杂的树型结构数据
请求：
<request><useId>1234<useId>           <-(表示的是键值对结构，key:userId,value:1234)<position>100*80</position>   (对象，本质上是键值对，属性名字是键，属性的值就是值）
</request>. ->(结束标签)
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++）