目录
外卖服务器场景带入
大佬们通用的规范格式
一、👦
外卖服务器场景
外面服务器沟通有很多模式——展示商家列表等等，只是其中一个，因此需要一个统一的规划了——不同应用程序，里面的自定义格式是不一样的，这样的设计十分灵活，最好要有一个统一的标准，
显示商家列表，有很多项，每一项包含了一些信息，商家名称，图片，好评率等等，距离你的位置，评分等等
设计：
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++）
