基于PostServeAction的WireMock请求响应DB存储扩展触发异常问题

• WireMock 内置的PostServeAction全局触发逻辑存在固定边界：仅会对业务端口上非/__admin前缀的请求执行doGlobalAction方法。所有管理类接口（包括stub映射提交、查询等/__admin/*路径）走独立的隔离处理链路，不在PostServeAction的触发范围内，因此提交mappings请求时，两个扩展方法都不会被触发；而访问业务端点/some/thing时符合触发条件，仅doGlobalAction会被调用。
• doAction方法本身不具备全局触发能力，必须在单条stub的定义中，通过postServeActions字段显式绑定扩展名称、传入对应参数后，才会在匹配该stub的请求处理完成后触发。当前没有任何stub关联你实现的db-request-recorder扩展，因此该方法永远不会被调用。
• 测试代码存在隐藏bug：向/__admin/mappings提交请求时，设置的Content-Type为application/x-www-form-urlencoded，不符合接口要求的application/json规范，加上异常捕获块没有任何日志输出，提交的stub大概率创建失败，问题被静默吞掉了。

要实现全链路（包含mappings管理接口）的请求响应入库能力，仅靠PostServeAction无法覆盖admin链路，需要做两处调整：

• 业务路径的请求记录：保留现有RequestRecorder里doGlobalAction的实现，这部分已经能正常捕获所有业务端点的请求和响应，直接在该方法内追加数据库写入逻辑即可。
• 管理接口（/__admin/*）的请求记录：新增实现AdminApiFilter扩展点，该扩展点会嵌入所有admin接口的处理流程，能够完整捕获admin请求的入参、返回的响应内容，在该过滤器的逻辑中追加数据库写入逻辑，即可覆盖提交mappings等管理操作的记录需求。

注：WireMock设计上对业务链路和管理链路做了固定隔离，没有配置项可以让PostServeAction直接捕获/__admin路径的请求，不需要尝试调整PostServeAction的参数去适配admin接口场景。

内容的提问来源于stack exchange，提问作者Ambuj Jauhari