mock server相关解决方案

先后端分离以后

先后端分离后, 你们今后进入了所谓的并行开发时代. 一旦完成先后端的(边界)分工, 你们就能够各司其职了.

前端在与后端交互时, 要想有效地提升工做效率, 后端的接口文档就是重中之重了.

接口文档还不够

所谓的接口文档, 即一份数据的契约书. 前端的全部逻辑和展示所有依赖接口文档中规定的数据结构.

可是光有接口文档不足以提高前端的开发效率, 由于前端开发时, 必须调用实实在在的接口和数据才能看到结果, 尽早跑通全部的前端流程, 这才是效率的根本.

在先后端并行开发的时代, 前端开发时, 后端也才开发, 接口尚未开发完, 后端拿什么给前端调用.

那么问题来了, 咱们怎么作一份可以调用的接口文档呢?

假数据时代

前端不能够傻傻地等后端接口开发完, 才开始作前端的逻辑, 所以咱们习惯了作假的接口数据, 让前端工做能够顺利地进行下去, 加快开发进度.

那么咱们都尝试过哪些手段来作假数据呢?

• 原始的静态数据文件

  例如将 mock-data.json 放在项目的根目录, 直接经过 ajax 调用便可.

• 使用 puer 或相似工具提供的 mock 功能

  须要一个 route.js, 在里面实现接口来提供假数据

  mock请求

  假设你的静态页面开发到必定程度，须要与服务器端交互了，然后台服务还彻底没法联调，这实际上是属于最简单的先后端分离开发的场景。通常而言， 做者会经过如下几种方案。

  • 层级1: 经过代码解耦，直接在前端mock数据

    这种方式影响较大，并且不管你解耦的如何，都会增长最终上真实环境的切换成本。

  • 层级2: 经过fiddler等调试代理工具mock数据

    优势是到正式环境的切换成本小，但配置成本较大，也接口mock也有局限性并基本上只能是静态数据模拟。

  • 层级3：利用puer无痛的解决这个问题

    puer提供了叫插件(addon)的功能，集成了express的route.js来达到最简的路由配置，能够提供基于真实http请求与相应的动态的mock数据。

这些方法的弊端很明显了, 用过的都知道, 太缺少灵活性了, 假数据还不够假, 不方便作随机的输出.

• 静态数据文件就不用说了, 文件里面就几条死的数据, 确定作不到随机变化. 假如前端须要看 100 条数据的结果呢? 你是复制粘帖 100 次吗?
• 依靠 puer 能够加入随机因素, 但随机机制还得本身去实现, 不够方便

那么咱们使用前端的 Mock 库来实现随机的数据机制, 不就 OK 了吗?

因而我尝试了 Mock.js, 在前端解决前端的假数据问题.

<script src="http://cdn.bootcss.com/zepto/1.2.0/zepto.min.js"></script> <script src="http://rawgit.com/nuysoft/Mock/refactoring/dist/mock-min.js"></script> <script> // 拦截 ajax 请求输出假数据, 至关于定义了一个假的接口 Mock.mock('/api/users', {  'users|1-10': [{  'id|+1': 1  }] });  $.ajax({  url: '/api/users',  success: function(result) {  console.log(result);  } }); </script>

由于 Mock.js 能够拦截前端的 ajax 请求, 所以我只要在开发时按照接口文档给出的接口和数据, 让 Mock.js 去拦截接口并提供随机的假数据便可, 例如实现一个开发时用的 mock-api.js.

<script src="http://cdn.bootcss.com/zepto/1.2.0/zepto.min.js"></script> <script src="http://rawgit.com/nuysoft/Mock/refactoring/dist/mock-min.js"></script> <script src="mock-api.js"></script> <script> // 前端的业务逻辑正常开展, 彻底无感知 $.ajax({  url: '/api/users',  success: function(result) {  console.log(result);  } }); </script>

当后端接口开发完成后, 去掉 mock-api.js, 便可切换到后端接口, 前端代码不须要作任何修改.

mock server 才是将来

在前端使用 Mock.js 是能够造出一个"假的接口", 还能够配置出随机数据, 但毕竟不是真正的后端接口, 还须要在前端引用一段定义假接口的代码(例如 mock-api.js), 势必会形成管理上的问题. 想想若是有 20, 30 个页面都要引用了 mock-api.js, 后端接口完成后, 你千万得记得将 mock-api.js 从这些页面中去掉, 是否是以为有点累赘, 不够智能啊.

看来是时候本身写一个 mock server 来提供假接口假数据了, 为前端提供像模像样的假后端接口.

基于上面的那些实践, 忽然就有了灵感, puer + mockjs 怎么样? puer 来提供 mock 机制, Mock.js 来提供随机数据, 因而 puer-mock 就诞生了.

puer-mock

puer-mock = Puer + Mock.js = 一个简单易用 mock server, 为你提供可配置的接口和随机数据.

使用了 puer-mock 后, 你只需像这样来配置接口

{
    "api": { "GET /api/users": { "response": {} } } }

而后调用这个接口查看结果

puer-mock 还提供了内置的 API doc, 能够看到你定义的全部 API

puer-mock 具备如下特色

• 简单配置便可定义 mock 接口, 不须要你写代码
• 配置接口及时生效, 修改即用
• 支持 JSONP 的方式调用接口
• 支持 CORS 的方式跨域调用
• 帮你输出一份接口文档, 方便在开发过程当中沟通交流

固然 puer-mock 还不仅有这些功能, 让你一秒钟就能拥有一个强大的 mock server, 因此请不要再本身手工作假数据了, 赶快尝试一下让你的工做效率翻番吧!

接口管理平台

有了 mock server, 能够帮助咱们解决掉一些先后端接口协商的问题, 但 mock server 并无解决掉全部先后端接口的问题, 例如:

• 后端接口修改了怎么办?

  他修改他的, 没有通知你怎么办? 你的 mock server 仍是老的数据结构, 这就是 mock server 与真实接口的同步问题.

  所以最好的办法仍是由后端提供一个 mock server 给前端使用, 即便他们的接口尚未开发完成. 这样当实现后端接口的代码发生改变时, 保持 mock server 也同步更新.

• mock server 应该是真正的后端接口 server 的一个开关功能

  mock server 实际上是供开发时使用的, 宗旨在于提高前端的开发效率, 并下降沟通成本, 当后端接口尚未开发完时, 前端就能够先作本身的事了.

  那么咱们更进一步来说, mock server 能够看做是真实的接口服务器提供的一个附加功能而已. 当某个后端接口尚未开发完时, 他提供 mock server 服务, 当接口开发完, 他就提供真正的后端接口了, 这样对前端来讲彻底是无感知的.

所以理想的 mock server 最好由后端来提供, 由于接口是由后端来实现的, 并且 mock server 的配置最好是根据后端代码来生成(例如经过注解的方式), 这样一来后端代码的修改就能方便地同步更新 mock server, 这就是咱们理想中的接口管理平台.

那么咱们总结一下接口管理平台应该是怎么样的? 若是有这么一个统一的接口管理平台, 团队协做是否是会更加的高效.

• 由后端接口服务器提供 mock server 功能
• mock server 的配置由后端代码生成
• 后端接口未开发完成时提供 mock 数据
• 校验接口的输入, 即输入参数是否符合接口的定义, 以前咱们都只是作了 response 的约定, reqeust 约定也很重要
• 控制 mock server 的开关, 能够控制一个接口是处于 mock 模式, 仍是真实模式
• 还能够延伸出更多的可能性, 例如作接口自动化测试

如下是目前的一些实现方案, 能够做为接口管理平台的技术选型.

• RAP

  RAP经过GUI工具帮助WEB工程师更高效的管理接口文档，同时经过分析接口结构自动生成Mock数据、校验真实接口的正确性，使接口文档成为开发流程中的强依赖。有告终构化的API数据，RAP能够作的更多，而咱们能够避免更多重复劳动。

• AMP

  Api manage platform

• Creating Help Pages for ASP.NET Web API

  When you create a web API, it is often useful to create a help page, so that other developers will know how to call your API. You could create all of the documentation manually, but it is better to autogenerate as much as possible. ASP.NET Web API provides a library for auto-generating help pages at run time. Swashbucklethat uses ApiExplorer to generate Swagger Docs.