接口调试(下)——让接口服务器为前后端解耦

api-server.png

写在前面

有半个月没有更新博客了,倒不是因为学习分享的积极性降低了。因为这半个月在做一件对于我来说很有意义的事情:写接口服务器。

拿来主义or重复造轮子?

在有限的时间和精力下,我还是比较推崇拿来主义的。所以我不似乎想验证自己的实力来重复造轮子,实在是看了很多接口文档服务器都不符合我的要求。其中比较优秀的是swagger,但是核心功能是java写的,要我打开eclipse再写java,我内心是拒绝的~项目上一直在使用的redmine,看上去比较清晰,但是编辑方式并不算友好,还有apidoc,都是只能支持API文档查阅和编辑的功能,功能太薄弱。

原理

这次编写的接口的服务器的功能设计是想按照Martin Fowler在一篇文章中提到的 契约测试 的思想来实现的(虽然并没有完全实现)。契约测试的核心就是双方都保证按照约定好的接口进行开发。前端对请求参数进行验证,后端对返回结果进行验证。时间关系,这个功能我没有完全实现,但是作为替代,对于前端提供了mock服务器,提供假数据,对于后端可以发送请求,测试接口,只是接口的校验还不能完全自动化。这样的好处就是保证前后端分离,实现高效开发。

技术

当我写这篇文章的时候,其实我内心是很欣慰的。因为:

MEAN

使用了我一直很看好的MEAN技术。我看中MEAN的原因以及MEAN的优势可看我另一篇文章《MEAN杂谈》。总体感觉编写比较流畅,但是很多细节方面需要自己把控,需要按需添加第三方模块。

前后端分离

提供假数据和发送请求并管理API文档,为了实现这些功能,需要两个服务器配合。一个用来发送请求和管理文档,另一个负责提供mock数据。

测试

终于开始在项目中编写测试代码了。当我看到调查中显示一半的开发人员不写单元测试的时候并不吃惊,但是忧心忡忡,因为自己的写的代码根本无法得到保障,只靠鼠标点一点根本不能高效地测试出bug。而且最大的问题是不具有回归性,当功能新增和修改之后,很容易出现之前修复的bug又复现的情况。关于代码测试,我在浏览器端测试代码写完后做一次总结。

目录结构

和express默认结构相似。

1
2
3
4
5
6
7
8
9
10
11
--bin    启动文件
--public 浏览器端的静态文件
--javascripts 业务脚本
--lib 第三方插件,包括脚本和样式文件,bower管理
--stylesheets 业务样式
--routes 路由逻辑
--test 测试代码
--views 浏览器端模板,handlebars
app.js 加载中间件,根路径拦截

readme.md 英文版自述文档
readme_zh.md 中文版自述文档

下一步

  • 国际化。加入i18n模块,让项目支持多种语言。
  • 前端测试。目前的测试代码只覆盖了服务端,浏览器端没有进行测试,需要完善。
  • 参数校验。前端请求参数校验和后端返回结果校验,当前后端和接口不一致时,服务器可以强行校验并报警,这才算真正的契约测试。
  • 搜索功能。优先级排后,页面上可以对名称、路径搜索,能满足基本需求。

项目

https://github.com/yalishizhude/api-document


热评文章