处理get请求是为了让微信服务器和公众号服务器接头，说白了就是对暗号的过程。微信服务器发过来一个“天王盖地虎”，我们的公众号服务器回一个“宝塔镇河妖”，那肯定是不行的。完成这个过程要借助别人都不知道的token，如果请求中发过来的signature经过验证是有效的，就把echostr还给它，如果无效，就回它“认错人了吧!”。那如何正确的设置微信公众号的被动回复，接下来南昌微信开发公司--百恒网络来详细讲解。

处理post请求是为了回应用户发过来的消息或触发的事件，让用户能跟我们的公众号服务器愉快地玩耍。但因为这些消息和事件是放在xml里发过来的，而且响应的时候也要用xml格式封装好，所以除了业务逻辑，还要处理xml的解析和封装。

说到xml解析，因为有express-xml-bodyparser这样的middleware存在，并且这个轮子也不在我们的学习范围里，就拿过来直接用了。

除此之外，既然只有第二项的业务逻辑部分是不同的，那其他的部分我们就可以像webchat一样，搞一个共用的库。而我们对这个库的要求也很简单：

能验证signature

能提供json格式的消息给我们

能把json格式的返回消息封装成xml

而这个库的用法，我们希望是：

在get请求处理函数中把验证signature需要的数据给它，让它告诉我们true还是false

在post请求处理函数中把消息或事件给它，让它把要返回的xml数据给我们

它在处理消息或事件时，能调用我们提供的消息或事件处理函数，给我们json格式的消息，接收我们函数返回的json结果

综合上面这两种考虑，用ES 6的类实现模板方法模式。因为这个类干的是为微信服务器提供服务的工作，决定管它叫Waiter。我们的Waiter类有三个方法：

verifySignature：验证signature

process：处理接收到的消息，调用业务逻辑，将返回结果封装成xml返回

populateReply:由process调用，子类要实现的业务逻辑就放在这里

总体来说，完成后我们的应用大概是下图这个样子的：

具体实现以keystone为基础，首先来看我们的路由定义：

针对/api/weixin的post请求添加了中间件xmlparser。

verify的定义非常简单，只是调用waiter的verifySignature：

handle的定义更简单,把req交给waiter去process，得到结果，将响应的Content-type设为xml，然后把reply send出去:

DWaiter是Waiter的子类，只实现了populateReply方法：

这个实现也很简单，只处理了文本、图片和语音三种消息，收到什么就回复什么;其它的全不理。

最后是Waiter类：

代码非常简单直白，verifySignature跟webchat的是一样一样一样的，process在签名验证通过后，从req.body.xml中获得解析好的消息或事件，交给populateReply，然后根据populateReply返回的消息类型封装成不同的xml数据。

本文仅限内部技术人员学习交流,不得作于其他商业用途.希望此文对广大技人员有所帮助。文章出自:南昌微信开发公司-百恒网络：http://www.jxbh.cn