接口有什麼用？
作為一個互聯網公司，很多資源和信息需要內部共享或外部流通，那相關的數據就需要通過接口來傳輸。
無論是2C還是2B的產品，都會用到接口，其中2B的產品們——數據、後臺、開放平臺/供應鏈，幾乎和接口都是正面接觸。
接口怎麼用？
目的千差萬別，用法殊途同歸。本文主要以美團門票舉例，介紹接口的基本屬性、產品邏輯和異常情況等，供大家參考和討論。
怎麼理解接口？
API接口是Application Programming Interface的簡稱，是一些預先定義的函數，包括接口地址、傳入參數和返回參數。
可以簡單理解為，當需要訪問某些數據，正常狀態下傳入合格參數，會收到該數據範圍內的返回參數。
場景：用戶選定時間、地點後，搜索航班；後臺會調用搜索接口，傳入時間、地點等參數，接收航班類別、價格等參數，在前臺頁面上進行排列展示。
同理，下單時會調用生單接口確認是否成單，支付時會調用支付接口完成交易，自動修改訂單狀態。
產品邏輯
很多公司都有開放平臺（也叫供應鏈），比如美團作為一個平臺，很多的供應商需要把自身資源導入平臺，在平臺頁面上集中展示，供用戶選擇。
一般情況下，美團會有自身的一套接口，供應商可以開發對應的接口進行對接，這種叫（運價）直連。
以下以美團門票為例，此鏈接（ http://open.trip.meituan.com/ ）是商家對接的開放平臺，不涉密，商家技術、業務人員可以通過該地址上的接口說明進行商家對接。
- 01 後臺流程
門票直連繫統是通過接口，把商家的門票數據導入到美團上收單，按用戶行為軌跡來說，實現“搜索-預定-下單-支付-售後”的自動化。異常情況通過郵件等形式預警，手工介入處理。
①正常情況下，涉及前臺和用戶行為的業務流程：
②涉及後臺的產品數據&訂單狀態更新（部分簡略）：
- 02 接口分類
按接口類型和屬性可分為三類：數據類、交易類和通知類。有一部分為美團接口，另一部分接口需要商家進行開發。
①數據類：商家數據對接到美團（涉及到商家的4個接口，拉取產品信息、產品變化通知、拉取景點信息、拉取價格日曆）
②交易類：“用戶——美團——商家”的交易行為（涉及到商家的5個接口）
③通知類：包括商家開發的已出票、票已使用、已退款3個接口，美團自有的已退款、查餘額、編審狀態通知的3個接口。
怎麼監控和處理異常？
異常主要為兩類——接口問題、產品問題。
接口問題就是無響應、響應過慢、重複響應等，產品問題就是存量少、變價快、時間差導致下架更新不及時等。
在考慮每一步的流程時，需要兼顧異常問題的發生與解決方法，儘量避免用戶體驗損害和商家損失。
一般的解決方法是數據監控，通過對每個業務節點的多項指標進行監控，一旦超出閾值，就可以用郵件、短信等形式通知相關人員，及時解決問題。
接下來我們從兩個方面具體探討如何應對這些問題。
用戶
- 01 用戶體驗——具體場景&數據監控
對用戶來說，流程的任一節點不順暢，都會導致體驗不好，故根據用戶行為軌跡來進行數據監控。
①頁面展示慢——接口響應時長、用戶頁面停留時長、跳失率
Reason：實時調接口查詢景點&產品信息，因數據量大或頻率快導致。
Solution：緩存數據，每N分鐘更新一次。
②數據展示異常——後臺返回接口異常的次數和概率
Reason：接口超時或異常。
Solution：可以設定重複調用，多次重試失敗後，通過郵件等形式通知到運營、技術或商家。
針對數據型接口，對產品進行下架或隱藏處理。
針對交易型接口，下單、支付的問題可以提醒用戶、為用戶推薦同類產品、對產品進行下架或隱藏處理；退票類問題可以建議用戶之後重試，如果比較緊急可以聯繫客服加急處理。
針對通知型接口，不涉及用戶，郵件處理即可，可人工介入更新信息。
③產品變動，特別是變價——下單失敗率、變價率、出票失敗率
Reason：數據更新有時間差。
Solution：當某一產品的失敗率或變價率超出規定，可隱藏或下架；針對某些產品庫存少的情況進行提示，預告風險；設定合理的定時更新任務。
④下單/支付/退票失敗——失敗率、失敗原因
Reason：用戶可能多次提交，或者訂單已使用、已關閉等客觀原因，無法成功。
Solution：需要加入檢驗機制，比如在短時間內重複提交不調用接口，直接返回原結果；善意提醒用戶不要重複提交，如“您的手太快了，請休息30s後再試”；可以提供IM人工或電話諮詢、留言等選項。
⑤服務響應時間長——手工操作訂單量和佔比
Reason：比如用戶提交退票後長時間不退款；支付後長時間不出票
Solution：定時調用訂單查詢接口，更新訂單狀態並短信/推送消息告知用戶；超過服務規範時間前發送預警郵件，人工介入處理。
商家
- 02 商家體驗——數據監控&具體場景
對商家來說，用戶體驗不重要，轉化率和利潤才是重點，故數據監控
以業務指標為主。①重複生單、生單不支付佔庫存——訂單量、訂單支付轉化率、支付失敗率、庫存佔用量和支付量
Reason：用戶手速太快；惡意佔庫存
Solution：制定規則，同一人只能佔一個庫存；同一訂單最多隻能訂N個人。
②惡意重複調用接口——涉及到的每個接口調用頻率
Reason：比如短時間重複調用某一接口
Solution：規定同一IP地址不能在短時間內多次調用；直接返回第一次調用接口的結果，不再重複調用；每個接口在同一時間最多N次調用，否則返回失敗等。
③因數據更新不及時等導致的虧損——（佣金、廣告）投入產出比、人為損失
Reason：用戶使用後退款完成、用戶支付後變價等
Solution：根據時間差、處理規則來明確劃定責任方。
④結算問題——財務對賬自身支出（退款）和收入
Reason：平臺和商家以“T+N”的方式結算
Solution：B端訂單系統裡的財務對賬功能，可以用郵件形式每日發送；監測異常數據，如當日無結算、結算金額與訂單金額不一致。
以上即為接口主要的應用對象和邏輯，邏輯不難但複雜度高，需要細心周到地考慮各種情況，希望能與大家一起討論。
閱讀更多 一個有故事的互聯網人 的文章
