背景

无论是出于开发效率考虑,还是出于优化架构考虑,前后端项目分离,两班人马并行开发已经成为常见的开发模式。相比在接口发布之后再启动前端开发的模式,分离并行开发也给前端带来了更多的挑战:

  • 浏览器跨域问题:由于接口不在同一个项目,所以前端在本地开发时无法直接调通后端接口;
  • mock 问题:接口可用之前,需要本地先 mock 返回数据;
  • 不同环境连调问题:由于往往存在开发、测试、预生产和生产环境,前端项目要能够在不同环境自由切换,并且不用修改代码。

如何优雅地解决上述问题,在《前后端分离开发中前端需要克服的挑战》中已经详细描述,总结就是通过环境变量来触发调用接口的代码指向 mock 或者不同环境。《前后端分离开发中前端需要克服的挑战》解决了前端开发的问题,理论上前端只要针对 mock 数据开发,配置好不同环境的接口端点,发布到不同环境之后就不用管了,如果接口完全按照 mock 定义的契约实现,不应该有任何问题。

但是现实中还是免不了出乎前后端开发的意料,明明 mock 数据时好的,到了对应的环境就是对不上。在连调过程中,往往碰到前后端各种冗长的无效沟通:前端问后端问什么没有返回 xxx?后端问前端:你传的参数是什么?前端告诉后端:xxx;后端说我调用是好的呀,你说的是那个环境?……

几个小时下来,要么发现聊的不是同一个环境,要么发现是某个神奇的 header 字段导致,等等。那么,怎么避免这种不必要的不精确的沟通呢?

cURL

cURL 是解决这个沟通问题的救星。前端碰到接口调用问题,直接将异常请求以 cURL 形式发送给后端,不需要手动生造请求,只要在开发者工具中选中这个异常请求,右键复制成 cURL 即可。
image.png
cURL 以文本形式携带了请求的所有信息,接口端点、请求头和参数等等,后端拿到后就有了所有的信息,不需要再多问一句,而且可以快速重放请求,做有针对性的参数修改等等以排查问题。

Postman

当然,后端甚至不必只在命令行做纯文本形式的修改,他可以直接将 cURL 文本导入到 Postman 里,从而使用 GUI 来操作这个请求,以及顺便保存了所有的操作历史,非常方便:

image.png
image.png