@no13bus

关于 puer-mock 使用过程中的常见问题答疑
https://github.com/ufologist/puer-mock/blob/master/FAQ.md

@no13bus 能够交流再好不过了，可以在 puer-mock 的项目中发 issue 来交流下

@leqoqo 已经发布了 1.2.0 版本, 欢迎使用

@leqoqo 分页为什么需要定义两个接口呢？难不成需要第一页和第二页返回不同结构的数据？

puer-mock 只验证客户端是否传入了必要的参数，不承担实际的业务逻辑，毕竟是 mock server ，不考虑实现很复杂的验证逻辑

因此你可以这样定义接口
"POST /list": {
"request": { // 仅验证参数
"body": {
"limit": 20,
"offset": 0
}
},
"response": {
"data": {
"list|1-10": [{
"id": "@id"
}]
}
}
}

@leqoqo puer-mock 的路由配置是完整支持 RESTful 的

看到你想对 form 参数进行一些过滤, 是指什么? 是指对请求参数做一些验证吗?

如果是这个功能, puer-mock 接下来的 1.2.0 版本即将支持这个功能

例如:
"request": {
"querystring": {},
"header": {},
"body": {}
}

完整说明请参考 example/_mockserver.json
https://github.com/ufologist/puer-mock/blob/master/example/_mockserver.json

@int64ago 感谢你提出的这些顾虑，也引发了我的思考，希望和大家共同探讨下

-----------------

在做 puer-mock 的时候，我参考了很多接口规范和接口平台，主要是从 Swagger 和 RAP 那里获得的灵感，希望可以尽量简单的通过 JSON 配置来定义一个接口，并生成随机数据，继而形成一个标准的接口文档(谁说接口文档只能是 word 之类的)。

如果形成了接口规范，我想后面的事情都是有可能的。

> 应该有个平台
puer-mock 目前比较适合中小型团队的前后端协作，因为是直接编写 JSON 文件做为接口文档的，因此需要双方都熟悉配置，对于技术团队没什么大问题，定义接口的方式也足够简单，基本上熟悉 HTTP 的，看一眼就明白这些接口的定义了。

如果要更友好些，那就需要做一层 UI ，做一个系统，一个平台，通过可视化的手段来生成接口配置文件就好了。所以说定义好接口规范是最基础最重要的第一步， puer-mock 尝试做好这一步。

> 平台的修改应该很容易反应到本地 Mock 数据
puer-mock 支持修改了接口配置后马上生效，应该还是能够满足大部分需求的

> Mock 生成的数据应该同时对 iOS/Android/... 都友好
puer-mock 生成的 mock 没有针对某个客户端，属于后端接口规范，对客户端都是友好的，也没有任何侵入性

> Mock 数据的定义应该可以自己插入一些简单逻辑
puer-mock 后面是通过强大的 mock.js 来生成 mock 数据，因此针对"某个字段只返回 1-10 之间的数字"这样的需求是完全满足的。
例如配置方式如下
"field1": "@integer(1, 10)"

> Mock 数据的定义应该考虑到可复用性
puer-mock 在参考 Swagger 规范的时候就意识到了这个问题，但出于简单的考虑，暂时只能复制粘贴那些重复的 response 定义，这确实是埋了个坑，但对于中小型团队应该还好啦，有规范总比没有的好。关于这点， puer-mock 考虑以后是否通过 Swagger ref 的方式来引用预先定义好的数据结构，或者通过上层的接口平台来解决这个问题，将数据结构定义在接口平台，让接口平台来生成重复的数据结构引用，来避免手工复制粘贴造成数据结构出现潜在的不一致性问题

> Mock 的管理应该区分用户权限
这个不在 puer-mock 的考虑范围，上层的接口平台可以来做这个事情，这也是为什么越往后统一的接口平台越重要的原因，形成部门级公司级的协作流程

> Mock 接口和数据定义后，应该可以有条件直接生成文档
目前 puer-mock 内置了接口文档，可以在线查看，虽然还比较简陋，只是格式化展示了接口定义的 JSON 文件，做了分组便于查看。但根据接口定义的 JSON 输出接口文档完全是可以自定义的，所以想生成一份高大上的接口文档完全没有问题

-----------------

最后说下目前 puer-mock 已经在我厂中推行，有 3 个项目(小公司项目本来就不多啊，大家见笑了)使用了，定义了 50 多个后端接口，前端 /App 端 /后端都表示很实用，确实提高了工作效率

@chrishine 有缘啊, 我也用过 moco, 但貌似不能做动态可变的假数据, 只能是写死的假数据, 配置起来也不是很直观, 是基于 Java 实现的, 对于前端来说可能不太方便定制.

https://github.com/dreamhead/moco

@int64ago 感谢你的分享, 长知识了, puer-mock 相比 NEI, 根本是没法比了, NEI 是一个完善的接口管理平台, 而 puer-mock 仅仅是为了方便大家快速定义接口做一个 mock server 而已.

说到造轮子, 可能是我见识少, 没有看见过 puer-mock 这样的轮子, 纯粹是为解决自己遇到的问题, 如果要论可用性, 我自己觉得很方便, 已经够用了, 其他准备使用的小伙伴们如果有问题可以发 issue 或者 pr, 或者再造一个更好的也无妨.

另外看了一圈 NEI , 不知是否可以算是网易公司(内部?)级别的东西, 感叹大公司就是好啊, 如果所有团队都能够这样统一作业, 可谓是行业的又一大进步, 值得我们学习. 感觉和阿里系的 RAP 有部分功能类似.
https://github.com/thx/RAP

@microchang 试用了一下 fake.llchangll.com , 可是没有找到在哪里可以定义接口的参数?

http://storage1.imgchr.com/images/fakeapi.png

@rainysia 据我所知 swagger 可以定义接口，做为接口文档，但如果后端接口还没有开发完，前端难道不需要 mock 吗？
这时候前端一般的做法就是自己手工做假数据，但这样做的效率和方式都不理想，所以才做了 puer-mock 项目

@li24361 我在测试 70c.html 这个demo的时候也遇到了这个现象, 但不用担心是bug, 出现这个问题是由于 demo中引用的 responsive-page.js 通过 rawgithub.com 来提供, 下载速度会比较慢造成的延时, 如果是自己 host 的时候是不会出现这个现象的.

如果有任何bug或者问题, 请发个 [issue](https://github.com/ufologist/responsive-page/issues) 给项目, 非常感谢.

如果仅是用于合并CSS及其依赖的问题, 可以考虑用 requirejs Optimizer CSS合并机制.

使用requirejs optimizer 可以优化 css
http://requirejs.org/docs/optimization.html#onecss
使用方法:
页面中只加载一个main.css, 其他依赖的css都通过 @import 方式导入
最终发布时通过requirejs optimizer这个main.css, 会得到一个合并了所有依赖的css(正确的更新了css中的url引用)

从 http://jinjiang.github.io/h5slides/demo#40 这里看见的
* 现有的CSS压缩库多半都是针对单个文件
* 很少针对@import语法进行文件合并
* 很少针对url(...)的相对路径进行修正
RequireJS Optimizer 做到了上述几点
Optimizes CSS by inlining CSS files referenced by @import and removing comments.
Note: The url() path fixing will always fix the paths relative to the cssIn build option path, not the out build option.

@yeelone 如果直接不看也可以, 代码只是为了一步步证明而已, 重点在于自己实践

@lidashuang 不好意思, 让大家费神了...

@jinwyp 纯属个人理解, 对于新手而言可能略显复杂了, 但也算是经典示例所以就拿出来讲讲

@gangsta 没有办法, 豆瓣不支持, 但是我喜欢豆瓣简约/快速的风格, 大家将就着看吧, 反正实际的代码也是需要自己来运行实践的

推荐去 http://microjs.com 里去找, 可以试试 https://github.com/ded/Reqwest, Includes support for xmlHttpRequest, JSONP, CORS, and CommonJS Promises A.

@wity_lv 同意技术栈的说法, 一般的前端(网页)开发, 是不需要用到文章中提到的N多东西, 也就是希望大家了解下可能会碰到的各种问题(其实我也没有办法全部列出来), 俗话说你永远也不知道你不知道的东西, 视野非常重要, 另外已经关注这个朋友的 github, 相互学习