如何设计「前后端交互协议」

客户端和服务器交互，web页面和后端交互，都需要设计前后端交互协议。究竟怎么样设计最好，是否有些方法论呢？有的。

方法很简单：前端侧重展示，后端侧重逻辑；轻前端，重后端。

理由如下：

安全性

无论是客户端，还是web页面，在黑客面前，都是可以修改逻辑的。所以重要的逻辑，都是要做在后端，即使是游戏为了性能和体验，在后端也要做校验逻辑。

逻辑在后端是省不掉的，至于前端，能省则省。不用相同的逻辑实现两次，以后升级修改，只要改后端就可以了，前端只要保证根据后端传过来的展示规则，正常展示就可以。

web页面还好，可以控制发布。但是客户端，分发就要用很久，而且用户不一定马上升级。所以对协议的制定要求更高，最好是只后端修改，前端就能用上新功能。

这样后端也好维护，不用根据客户端版本而写不同的逻辑。前端也不用关心后端是否有变动要一致。

前端只关心展示，相当于一个哑终端。服务器发下来什么指令，客户端就展示什么，并不需要了解业务逻辑。

出现问题也好查，展示问题前端负责，逻辑问题后端负责。只要把前后端交互的内容打印日志出来，就知道是谁的问题。

一个活动页面，用户进来展示一个中奖列表，列表有两只股票A和B。根据用户是否有交易过，B股票上展示一个「不可领取」的戳。

方案一：

前后端协议只有一个字段，用户是否交易过。

前端默认进来都展示A和B，根据从后端得到的字段，确定是否展示「不可领取」戳。

后端除了查询是否有交易过，也要每次查看用户是否有中过奖，领取过A或B。

问题：

如果哪天产品经理修改了需求，可以领二十支股票，前后端都要修改，而且每次前端都要把产品的逻辑领会全，根据产品经理的要求修改。每增加减少一支股票，都要修改，很烦。

怎么解决呢？

方案二：

前端后端协议是一个列表，列表中包含要展示的股票信息，有的字段表示是否展示戳。

前端不关心产品逻辑，只是按照这种来展示。

后端根据用户数据，把协议打包好，传给前端。

前后端可以想象为一个单机程序，如果写个单机程序，肯定是写一次逻辑。逻辑层负责实现逻辑和表现层展示UI，后端对应逻辑层，前端对应表现层。但是为什么网络的就要写两次呢，不是必须的。

协议要有扩展性，根据字段或版本号识别不同版本。

客户端要兼容不识别的字段，不要因为升级新字段不认识而产生异常行为（crash或逻辑出错）。