處理get請求是為了讓微信服務器和公眾號服務器接頭，說白了就是對暗號的過程。微信服務器發(fā)過來一個“天王蓋地虎”，我們的公眾號服務器回一個“寶塔鎮(zhèn)河妖”，那肯定是不行的。完成這個過程要借助別人都不知道的token，如果請求中發(fā)過來的signature經(jīng)過驗證是有效的，就把echostr還給它，如果無效，就回它“認錯人了吧!”。那如何正確的設置微信公眾號的被動回復，接下來南昌微信開發(fā)公司--百恒網(wǎng)絡來詳細講解。

處理post請求是為了回應用戶發(fā)過來的消息或觸發(fā)的事件，讓用戶能跟我們的公眾號服務器愉快地玩耍。但因為這些消息和事件是放在xml里發(fā)過來的，而且響應的時候也要用xml格式封裝好，所以除了業(yè)務邏輯，還要處理xml的解析和封裝。

說到xml解析，因為有express-xml-bodyparser這樣的middleware存在，并且這個輪子也不在我們的學習范圍里，就拿過來直接用了。

除此之外，既然只有第二項的業(yè)務邏輯部分是不同的，那其他的部分我們就可以像webchat一樣，搞一個共用的庫。而我們對這個庫的要求也很簡單：

能驗證signature

能提供json格式的消息給我們

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

而這個庫的用法，我們希望是：

在get請求處理函數(shù)中把驗證signature需要的數(shù)據(jù)給它，讓它告訴我們true還是false

在post請求處理函數(shù)中把消息或事件給它，讓它把要返回的xml數(shù)據(jù)給我們

它在處理消息或事件時，能調(diào)用我們提供的消息或事件處理函數(shù)，給我們json格式的消息，接收我們函數(shù)返回的json結(jié)果

綜合上面這兩種考慮，用ES 6的類實現(xiàn)模板方法模式。因為這個類干的是為微信服務器提供服務的工作，決定管它叫Waiter。我們的Waiter類有三個方法：

verifySignature：驗證signature

process：處理接收到的消息，調(diào)用業(yè)務邏輯，將返回結(jié)果封裝成xml返回

populateReply:由process調(diào)用，子類要實現(xiàn)的業(yè)務邏輯就放在這里

總體來說，完成后我們的應用大概是下圖這個樣子的：

具體實現(xiàn)以keystone為基礎，首先來看我們的路由定義：

針對/api/weixin的post請求添加了中間件xmlparser。

verify的定義非常簡單，只是調(diào)用waiter的verifySignature：

handle的定義更簡單,把req交給waiter去process，得到結(jié)果，將響應的Content-type設為xml，然后把reply send出去:

DWaiter是Waiter的子類，只實現(xiàn)了populateReply方法：

這個實現(xiàn)也很簡單，只處理了文本、圖片和語音三種消息，收到什么就回復什么;其它的全不理。

最后是Waiter類：

代碼非常簡單直白，verifySignature跟webchat的是一樣一樣一樣的，process在簽名驗證通過后，從req.body.xml中獲得解析好的消息或事件，交給populateReply，然后根據(jù)populateReply返回的消息類型封裝成不同的xml數(shù)據(jù)。

本文僅限內(nèi)部技術人員學習交流,不得作于其他商業(yè)用途.希望此文對廣大技人員有所幫助。文章出自:南昌微信開發(fā)公司-百恒網(wǎng)絡：http://m.gimmickmag.com