處理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.dgscpc.com