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

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

說到xml解析，因?yàn)橛衑xpress-xml-bodyparser這樣的middleware存在，并且這個輪子也不在我們的學(xué)習(xí)范圍里，就拿過來直接用了。

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

能驗(yàn)證signature

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

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

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

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

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

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

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

verifySignature：驗(yàn)證signature

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

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

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

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

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

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

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

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

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

最后是Waiter類：

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

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