自从盛行前后分离，二个不同的工种各自负责着自己的一亩三分地，后端只需考虑接口参数正确，接口正常，前端只需考虑页面效果达到即可。这种脱离的场景下最容易造就的问题也暴露了出来。
面对高并发，大数据访问时候，由于前端不合理调用后端接口，导致系统崩溃，这种锅很常见，甩给谁也不好，至于降级限流这种方案不在本讨论话题内。常规处理方案就是前后端都做防重复提交设计，后端利用redis判断，前端利用css在结果未返回前隐藏按钮。再深入的方案就是缓存处理了，将结果放入redis，加一个时效，到期后再去获取最新的。可是这些都是马后炮，所以在一开始开发的时候，就要充分考虑到这一点，不想求前端高抬贵手，就后端自己强制规范起来把。
出入参的规范，这一点也是前后对接的难点，而责任往往在于后端的接口设计。首先，后端必须要对出入参进行序列化与反序列化的定制，这样可保证出入参的数据类型是统一的，反映到前端就是全部接口数据类型的统一，前端会很舒服，不用考虑null不null这些糟心的问题。然后在对入参可以通过hibernate-validator强制校验，让前端对接口的时候失败的明白，对出参统一包装成对象，定义各种code，前端通过code在做不同的业务处理。比如操作成功200，弹出正常提示，比如业务异常201，弹出警告提示，比如程序异常202，弹出错误提示。这些都需要前后规范好
接口单一职责造就的前端烦恼，一个功能往往要调不止一个接口才能完成。不断的调接口，对前端也是一种折磨。后端设计接口的时候，想着每一个接口就是完成特定的一个作用，而不是功能。让前端通过调接口的方式去组装这些作用并成为功能，后端是挺爽的，前端就难受了。后面就是你不仁，休怪人家不义了。所以后端设计接口的时候，要以功能为中心，作用可以写分散，但是组装能在后端完成的尽量后端完成，减少前端的麻烦，也是给后端少埋雷。毕竟明明一个接口能解决的事，非要折腾不止一个接口，你的nginx不累吗?
2591
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
