客户端和服务器交互,web页面和后端交互,都需要设计前后端交互协议。究竟怎么样设计最好,是否有些方法论呢?有的。
方法很简单:前端侧重展示,后端侧重逻辑;轻前端,重后端。
理由如下:
安全性
无论是客户端,还是web页面,在黑客面前,都是可以修改逻辑的。所以重要的逻辑,都是要做在后端,即使是游戏为了性能和体验,在后端也要做校验逻辑。
逻辑在后端是省不掉的,至于前端,能省则省。不用相同的逻辑实现两次,以后升级修改,只要改后端就可以了,前端只要保证根据后端传过来的展示规则,正常展示就可以。
易于升级
web页面还好,可以控制发布。但是客户端,分发就要用很久,而且用户不一定马上升级。所以对协议的制定要求更高,最好是只后端修改,前端就能用上新功能。
这样后端也好维护,不用根据客户端版本而写不同的逻辑。前端也不用关心后端是否有变动要一致。
易于实现和扩展
前端只关心展示,相当于一个哑终端。服务器发下来什么指令,客户端就展示什么,并不需要了解业务逻辑。
出现问题也好查,展示问题前端负责,逻辑问题后端负责。只要把前后端交互的内容打印日志出来,就知道是谁的问题。
示例
一个活动页面,用户进来展示一个中奖列表,列表有两只股票A和B。根据用户是否有交易过,B股票上展示一个「不可领取」的戳。
方案一:
前后端协议只有一个字段,用户是否交易过。
前端默认进来都展示A和B,根据从后端得到的字段,确定是否展示「不可领取」戳。
后端除了查询是否有交易过,也要每次查看用户是否有中过奖,领取过A或B。
问题:
如果哪天产品经理修改了需求,可以领二十支股票,前后端都要修改,而且每次前端都要把产品的逻辑领会全,根据产品经理的要求修改。每增加减少一支股票,都要修改,很烦。
怎么解决呢?
方案二:
前端后端协议是一个列表,列表中包含要展示的股票信息,有的字段表示是否展示戳。
前端不关心产品逻辑,只是按照这种来展示。
后端根据用户数据,把协议打包好,传给前端。
前后端可以想象为一个单机程序,如果写个单机程序,肯定是写一次逻辑。逻辑层负责实现逻辑和表现层展示UI,后端对应逻辑层,前端对应表现层。但是为什么网络的就要写两次呢,不是必须的。
注意
协议要有扩展性,根据字段或版本号识别不同版本。
客户端要兼容不识别的字段,不要因为升级新字段不认识而产生异常行为(crash或逻辑出错)。