作者回复: 确实是个好办法,直接做一下强制转换能将错误提前暴露 感谢
作者回复: 疑问: 1. JSONP的响应也是在拼接字符串,是否也可以用template? 当然可以的,拼接字符串有多种方式,template也是可以。 2. 对于各种请求和响应格式的支持,是否也可以写成中间件的形式,让API更精简? 可以的,修改响应格式主要要先修改下context中的responseWriter,让输出先进入到我们定义的writer中,然后修改后再输出到前端。这样做可行。 不过更多的做法是封装一个公共方法,所有api地方调用这个方法。 3. 重复读取body的场景有哪些?我能想到的是某些访问控制的中间件可能需要事先检查body的内容。这样是不是就没法做流式处理(因为要把请求body读完才能做下一步的处理)?比如一边读取请求body一边写入响应body。 这个场景很多的,要打一个输入请求的所有日志到日志管理系统中,或者要实现一个回放功能,都有可能要读取请求body.
作者回复: 1 这里其实有三个逻辑,a 是否有这个key,b 这个key是否可以转换为目标对象, c 如果失败和没有,要怎么处理。目前是没有key返回默认值,有key但是无法转换返回零值,不过思考了一下,这里确实是改成“失败和处理”都返回默认值比较好。 2 parseParamsFromEndNode 这里传递的是request.URL.Path,是没有大写转换过的。应该不需要加这个