猫哥网络编程系列：HTTP PEM 万能调试法 - 猫哥_kaiye(3)_H5之家

由于 HTTP 1.0 尤其是 HTML 的规范与应用已经深入人心。大部分开发者能够很自然的这样理解：「GET」表示「读」操作，「POST」表示「写」操作。这样既可以保证中间组件与浏览器很好的利用 GET 的缓存机制，又能降低接口设计的复杂度。HTTP 之父 Roy Fielding 也说过「It is okay to use POST」：

Some people think that REST suggests not to use POST for updates. Search my dissertation and you won’t find any mention of CRUD or POST. （很多人认为 RESTful 建议不要使用 POST 用于提交更新，去翻一翻我的论文，压根就没提到过 POST 和其他「增查改删」方面的内容。）

但使用 POST 方法时尤其要注意：「使用统一的 Content-Type」。这是一个容易被新手忽略的细节，也是接口设计中经常出错的点。在上一期的《猫哥网络编程系列：详解 BAT 面试题》中有问到：

一个 POST 请求的 Content-Type 有多少种，传输的数据格式有何区别？

以下举例一些常见类型的 HTTP POST Request 报文，请注意其中的 Content-Type 与 Body 的对应关系（已手动删除无关 HTTP Header）

POST /test.php HTTP/1.1 Host: 127.0.0.1:8080 Content-Length: 54 Content-Type: application/json {"weixin_id":"imgXQB","weixin_name":"猫哥学前班"}

POST /test.php HTTP/1.1 Host: 127.0.0.1:8080 Content-Length: 74 Content-Type: application/x-www-form-urlencoded weixin_id=imgXQB&weixin_name=%E7%8C%AB%E5%93%A5%E5%AD%A6%E5%89%8D%E7%8F%AD

POST /test.php HTTP/1.1 Host: 127.0.0.1:8080 Content-Length: 259 Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryl60ti7CVoBj2kxfX ------WebKitFormBoundaryl60ti7CVoBj2kxfX Content-Disposition: form-data; imgXQB ------WebKitFormBoundaryl60ti7CVoBj2kxfX Content-Disposition: form-data; 猫哥学前班 ------WebKitFormBoundaryl60ti7CVoBj2kxfX--

只有客户端 POST 请求体的消息格式与其请求头声明的 Content-Type 一致时，服务端才能正确的接收与响应。因为许多后端的 Web 应用框架会遵照 HTTP 协议的内容协商原则（Content Negotiation）对响应体进行预处理，以提升开发体验。例如，Python 的封装了request.json、request.form、request.data 等一系列属性用于存放不同类型的来源数据。

3、接口 URI 与参数命名风格的一致性 4、返回数据结构的一致性

基本的返回体结构，可参考以下示例代码。

{ "code": "0", "message": "success", "data": { "id" : "1", "list" : [] } }

寥寥的几行代码饱含了几部深刻的血泪史：

当然，也有许多其他的方案可以解决上面提到的问题，但出于「最简」的原则，这样约定的理解成本最低。

最简 Mock Server

有了最简 API 的约定之后，实现最简 Mock Server 就相对简单多了。

1、编写返回的模拟数据

首先，我们按照 API 接口约定来新建一些模拟数据文件。例如新建一个「mock-data.json」的文件，将以上返回体数据保存其中。

2、运行 php 内置服务器

在命令行模式下运行 php 命令，Mac 用户直接打开终端即可，Windows 用户需要先安装 XAMPP 套件，并将 php.exe 所在的目录配置到系统环境变量中，再使用 CMD 运行以下命令：

php -S 0.0.0.0:8080 mock-data.json

开启之后访问任意 API 地址（:8080/any-api-uri-you-want/）均会返回 mock-data.json 的数据响应体。通过将 8080 端口换成 80 端口（Mac 需要使用 sudo 权限），再设置类似 127.0.0.1 的 HOST 配置，便可以模拟 API 的 Domain Host（）形式。

当然，也可以自己编写一个 index.php 的入口文件来实现一个基于 URL Path 规则的简单 Rewrite 功能，用来同时支持多个 API 的数据模拟。

使用 Fiddler/Charles 的 Map Local 功能

Fiddler/Charles 的 Map Local（本地映射）不光是用于 HTTP Edit，同样可以用于 HTTP Mock，当一个 404 请求（还未真正实现的 API）被代理服务器捕获后，可以设置映射到本地自定义的 mock-data.json 模拟数据文件，从而被模拟成一个正常的 200 请求。

自动化 Mock System 构想

迄今为止，我还未发现一个理想中的 Mock API 开源系统，如有哪位同学有见到过请在 Github 上留言周知，以下是我对最理想 Mock System 的构想：

「HTTP PEM」系统分析利器

这个接口很复杂，内部调用了好几个其他接口，如何定位问题究竟出在哪一步？

对于新人来说，最快的成长方式是不断地在新项目中实践，从头到尾参与到项目的每个系统细节的设计与讨论。如果能参与到重点、大型项目中，甚至幸运地得到大牛的亲自指导，成长速度将会突飞猛进。

但更多的情况是，新人作为离职程序员的补充力量来接手一个老项目甚至是烂摊子。面对一个复杂的陌生系统，吐槽与抱怨无济于事。这时，如果能使用「HTTP PEM 调试法」，从接口设计与调用的角度来剖析、理解整个系统的设计，就能快速上手业务。例如，PHP 程序员可以在项目代码中所有的 curl 调用点，将「CURLOPT_PROXY」设置成 Fiddler/Charles 的代理服务，然后一步步调试，从接口字段上理解数据库设计和 Controller 背后的业务逻辑。

最后，欢迎各位给我留言分享更多关于「HTTP PEM」和其他调试方法的经验与体会。