打开 Fiddler 菜单「Rules -> Customize Rules… 」,如果是首次开启会要求先下载安装 Fiddler ScriptEditor。打开 Fiddler ScriptEditor 之后,找到以下代码块(或使用菜单「Go -> to OnBeforeResponse」):
static function OnBeforeResponse(oSession: Session) { if (m_Hide304s && oSession.responseCode == 304) { oSession["ui-hide"] = "true"; } }
Fiddler Script 使用的编程语言是 JScript.NET(JavaScript 和 C# 的混合语法,类似 TypeScript),OnBeforeResponse 是 HTTP Response 响应前的事件函数,我们只需要在这里判断「如果开启了 Weinre Debug 功能,那么就在所有的 HTML 响应体中注入 Weinre Script」,以下是我修改的示例代码,覆盖以上代码块即可。
public static RulesOption("Enable Weinre Script") var m_EnableWeinreScript: boolean = true; public static var g_weinreScriptString: String = '<script src="http://127.0.0.1:8080/target/target-script-min.js#anonymous"></script>'; public static ToolsAction("Config Weinre Script") function ConfigWeinreScript(){ g_weinreScriptString = FiddlerObject.prompt("Text beblow will inject into HTML pages when 'Enable Weinre Script' rule is Enabled.", g_weinreScriptString , "Please Input the Weinre Script"); } static function OnBeforeResponse(oSession: Session) { if (m_Hide304s && oSession.responseCode == 304) { oSession["ui-hide"] = "true"; } if (m_EnableWeinreScript && oSession.oResponse.headers.ExistsAndContains("Content-Type","text/html")){ oSession.utilDecodeResponse(); if(oSession.utilFindInResponse("</html>", false)>-1){ oSession["ui-backcolor"] = "#5E30B5"; oSession["ui-color"] = "white"; oSession.utilReplaceRegexInResponse("<\/html>", g_weinreScriptString + '</html>'); } } }
修改保存后重启 Fiddler(或使用菜单「Tools -> Reset Script」)以生效规则,接下来运行「Tools」菜单中新出现的「Config Weinre Script」,将 127.0.0.1:8080 替换成自己本机的局域网 IP 与 weinre 服务端口号,同时开启菜单「Rules -> Enable Weinre Script」。至此,所有 HTML 页面将会被自动注入 Weinre Script,之后我们就可以在 weinre 后台中开始调试相关页面。以下是参考截图:
可以看到 HTTP 响应体中已经被动态注入 Weinre Script。
在 Mac Charles 下的 Script 注入配置更加容易,只需利用其 「Rewrite」功能进行简单的配置即可,参看下图:
通过 Fiddler/Charles 代理工具将 JS 脚本注入成功后,我们便可以通过前文提到的 weinre 后台开始 debug 相应的页面,以下是在 iPhone 模拟器中调试新浪微博界面的截图:
使用该方法可以调试 Android 和 iOS 中「任意 App 的 H5 页面」,但由于主要使用了 weinre 服务,其原理决定了该方法无法像真正的 Chrome DevTools 一样支持 JS 断点调试、Profiles 性能分析等功能,具有一定的局限性。在实际 Web App 开发过程中,推荐使用以下工具进行调试 :
由此可见,「HTTP PEM 调试法」是一个通用的 HTTP 接口调试方案,可以用来快速定位线上接口问题,对于开发人员来说掌握其背后的 HTTP 协议及其代理机制的原理更加重要,接下来我们聊聊常见的 HTTP 接口开发协作方法与 Mock 思路。
我的开发任务没法推进,因为某某的接口还没提供给我。
「HTTP PEM 调试法」之 Mock希望新手程序员在看完这一章节之后,不要再向你的项目组和上级反馈这样的说法,因为 HTTP Mock(接口数据模拟)是一项网络编程的基础技能,从实际项目经验来看,大部分基于 HTTP 接口的任务都可以并行开发。
最简 HTTP API不同岗位(例如前端开发与后台开发)或不同业务(例如订单系统与账户系统)的开发人员开始并行开发任务之前,首先要做的应该是对耦合和相互依赖的任务进行边界划分与规则约定。具体到某个 HTTP API 接口的约定上,至少应该明确以下信息:
针对以上三条信息,我设想的「最简」 HTTP API 包含以下几条原则,供各位参考:
1、不使用 RESTful API 来设计接口RESTful API 实际上是利用 HTTP 协议的语义(提交类型、返回码、)来将所有接口操作抽象化为一系列资源对象。这要求 API 的设计者与调用者都具备深厚的 HTTP 协议功底、语义化与抽象化能力。
2、只使用 GET/POST Method