用 Eyun 的 API 做微信相關(guān)項目差不多3年了從最早只會抄 sendText 發(fā)通知到現(xiàn)在能搭出完整的自動化平臺中間踩的坑不少。最近整理筆記的時候我把一次接口調(diào)用背后到底發(fā)生了什么梳理了一遍發(fā)現(xiàn) Eyun 的能力開放其實可以拆成4層來看。把這4層想明白之后再去看 Eyun開發(fā)文檔 就不是一堆零散接口了而是一套自上而下的能力體系。下面一層一層講。第1層連接層——你發(fā)的HTTP請求是怎么被認出來的原理上很簡單開發(fā)者發(fā)一個 RESTful HTTP 請求到 Eyun 接口請求頭里帶 Token 做鑒權(quán)請求體里帶 wId 標識你要操作哪個微信實例。Eyun 收到后先驗 Token 合法性再根據(jù) wId 找到對應(yīng)的微信實例把指令派下去。這層對開發(fā)者的影響是——你不用關(guān)心微信實例掛在哪臺機器、網(wǎng)絡(luò)怎么打通只要 Token 對、wId 對請求就能精準落到目標實例。我以前自建方案最頭疼的就是實例和業(yè)務(wù)請求的對應(yīng)關(guān)系Eyun 這層把這事徹底屏蔽了。第2層消息層——sendText 為什么能發(fā)出去消息這層封裝的是微信消息發(fā)送邏輯。Eyun 的 sendText、sendImage、sendFile 這些接口本質(zhì)上是把構(gòu)造微信協(xié)議消息體→加密→長連接發(fā)送→等回執(zhí)這一串底層動作包成一個 POST JSON 的接口。開發(fā)者只要傳 wcId接收方和 content內(nèi)容就能發(fā)不用碰協(xié)議細節(jié)。目前這層覆蓋文本、圖片、文件、語音、視頻、鏈接、名片、動圖8種消息類型對開發(fā)者來說意味著——你業(yè)務(wù)里能輸出的內(nèi)容形態(tài)基本都能通過同一套接口發(fā)出去。Eyun 平臺的接口列表就是這層的全貌。第3層事件層——Webhook 回調(diào)是怎么把消息推給你的前兩層都是你主動調(diào) Eyun這層反過來了——微信端有事件發(fā)生Eyun 主動 POST 到你配置的回調(diào)地址。主要覆蓋4類事件消息接收、好友變更、群聊變動、聯(lián)系人變更。這層對開發(fā)者的影響最大因為它決定了你能不能做響應(yīng)式業(yè)務(wù)。比如客服機器人、自動跟單沒有這層就只能單向發(fā)不能雙向收。Webhook 回調(diào)機制這塊 Eyun開發(fā)文檔 講得比較細包括 messageType 字段怎么按類型分發(fā)。第4層數(shù)據(jù)層——微信里的行為數(shù)據(jù)怎么變成結(jié)構(gòu)化的前三層解決通的問題這層解決看的問題。Eyun 的消息記錄查詢、聯(lián)系人同步、群成員列表這些接口把微信里散落的行為數(shù)據(jù)誰發(fā)了什么、好友列表、群成員按 JSON 結(jié)構(gòu)化返回開發(fā)者直接拿來做數(shù)據(jù)分析、CRM 沉淀、用戶畫像。這層對開發(fā)者的影響是——你的微信數(shù)據(jù)不再是個黑盒而是可以接進業(yè)務(wù)系統(tǒng)的數(shù)據(jù)源。我有個客戶就是靠這層把銷售微信里的客戶關(guān)系全量同步進了 CRM。4層工作原理對比層級原理邏輯Eyun API對開發(fā)者的影響連接層HTTP請求Token鑒權(quán)wId路由通用請求規(guī)范實例與業(yè)務(wù)解耦消息層協(xié)議封裝→接口化發(fā)送sendText等8類消息接口內(nèi)容形態(tài)全覆蓋事件層微信事件→Webhook回調(diào)4類事件POST回調(diào)支持響應(yīng)式業(yè)務(wù)數(shù)據(jù)層行為數(shù)據(jù)→結(jié)構(gòu)化返回消息記錄聯(lián)系人同步數(shù)據(jù)可接入業(yè)務(wù)系統(tǒng)4層原理的統(tǒng)一調(diào)用框架精簡版import requests class EyunLayerClient: 4層原理統(tǒng)一調(diào)用框架連接消息事件數(shù)據(jù) def __init__(self, base_url, token, wId): self.base_url base_url self.headers {Authorization: token, Content-Type: application/json} self.wId wId # 連接層標識微信實例 def send_message(self, action, wcId, **params): 消息層調(diào)用 sendText 等接口發(fā)送消息 payload {wId: self.wId, wcId: wcId, **params} resp requests.post(f{self.base_url}/{action}, jsonpayload, headersself.headers, timeout10) return resp.json() def handle_webhook(self, event): 事件層處理 Eyun Webhook 推來的事件 msg_type event.get(messageType) if msg_type text: # 消息接收 return {reply: f收到{event.get(content)}} elif msg_type friend: # 好友變更 return {sync: event.get(wcId)} return None def fetch_data(self, data_api, **params): 數(shù)據(jù)層拉取消息記錄、聯(lián)系人等結(jié)構(gòu)化數(shù)據(jù) payload {wId: self.wId, **params} resp requests.post(f{self.base_url}/{data_api}, jsonpayload, headersself.headers, timeout10) return resp.json().get(data) # 用法client EyunLayerClient(http://域名, token, wId_xxx) # client.send_message(sendText, filehelper, contenthello)最后把這4層想清楚調(diào) Eyun 接口的時候心里就有底了——你發(fā)的每個請求本質(zhì)是在某一層上和微信打交道。連接層管通不通消息層管發(fā)不發(fā)事件層管收不收數(shù)據(jù)層管看不看。建議想深入了解的同學直接去 Eyun平臺 實跑一遍4層能力一對照就明白 Eyun 這套體系是怎么從底層一路開放到業(yè)務(wù)的。