本文以被動請求接口為主，討論如何進行對外系統接口的產品設計。一起來看看~
本文以被動請求接口為主，討論如何進行對外系統接口的產品設計。一起來看看~
常見的To B產品有四類：
- 第一類為管理系統類產品，如CRM、ERP、BOSS平臺等；
- 第二類為辦公系統類產品，如OA；
- 第三類為商家端系統類產品，如給小B端用的商戶系統；
- 第四類為接口服務類產品，如聚合支付接口、人臉識別接口。
從產品形態上來說，前三類To B產品都具有用戶操作界面，其設計原則和C端產品的設計方法有很大的重合，可以借鑒C端產品的設計方法進行產品設計，例如尼爾森十大可用性原則、簡約設計方法等UE、UI設計方法就同樣適用于前三類產品的頁面設計。但第四類接口服務型產品沒有操作界面，產品形態是以API接口存在，所以設計的方式與C端產品就會有很大的不同。
一、產品經理需要關注哪些種類的系統接口
系統接口分為內部系統接口（公司內部系統與系統間的接口，例如數據中臺和業務系統的接口）和對外系統接口（提供給第三方調用的接口，一般都是基于HTTP/SOAP的協議接口，例如微信開放平臺提供給小程序開發者的接口），內部系統接口對于產品經理來說無需過多關注，例如服務器端都會面向APP提供調用接口，產品經理只需定義好APP的功能即可，具體APP和服務器的傳輸交互會由開發工程師來定義。
對外系統接口包含：主動推送接口（主動給第三方發送信息）、被動推動接口（被第三方推送信息）、主動請求接口（主動請求第三方獲取信息）和被動請求接口（被第三方請求獲取信息）。
二、如何設計接口類產品
系統接口類的產品設計需要定義如下內容：輸入內容、輸出內容、業務異常處理方式、計費邏輯、響應速度、并發量、易用性等。
1. 輸入內容
即第三方發送給我們的業務請求參數。產品經需要關注業務請求參數，同時明確參數是否可空，無需定義公共請求參數。例如數字證書在線生成接口（一般由CA公司提供的服務，應用調用該接口請求CA公司生成個人用戶數字證書或企業用戶數字證書），名稱、證件號碼、證件類別等信息屬于業務請求參數中不可空的參數，沒有此部分數據無法完成證書的生成；電子郵件、手機號等屬于業務請求參數中的可空的參數，缺省此部分參數也可完成業務；應用ID、加密因子、加密算法等參數屬于公共請求參數，公共請求參數內容無需產品經理設計，無需體現在需求文檔中。
2. 輸出內容
即接收第三方的請求后，經由系統處理后的業務返回參數。產品經需要關注業務返回參數，同時明確參數是否可空，無需定義公共返回參數。例如數字證書在線生成接口，第三方調用該接口后，系統需要返回cer格式的數字證書給第三方，cer格式的數字證書就是業務返回參數。輸出內容同樣需要明確參數是否可空，同時還需要明確是同步返回還是異步返回。
3. 業務異常處理方式
異常部分產品經理只需定義業務異常的處理方式，即產品經理對業務規則的要求。例如為保障圖片質量，要求第三方通過接口上傳的圖片需要大于100K，則需要產品經理明確指出在此要進行圖片大小檢查，若不符合規則即拋出異常。系統異常（如參數錯誤、參數缺失等）無需產品經理來定義。
4. 計費邏輯
即接口如何向第三方計費。
計費邏輯常包含兩部分：
- 第一部分是哪些情況下需要計費，哪些情況可以不計費，例如簡項比對接口（通過接口上傳用戶的姓名和身份證號碼，系統根據公安系統人口庫判斷輸入的信息是否一致，接口輸出比對一致、比對不一致、庫中無此號碼等結果），比對一致、比對不一致可以設置成計費，庫中無此號碼則可以設置成不計費。如果產品做得比較成熟的話，計費與否可以從后臺管理系統中通過返回結果碼自由配置。
- 計費邏輯第二部分是需要明確計費方式，計費方式大致分為按次計費（調用一次接口收取一次費用）、階梯計費（調用一次接口收取一次費用，但達到了一定使用量后單價有所下降）、按時間計費（包月或包年收費方式）。
即系統支持同時請求接口的最大用戶數量。通常并發量需求描述中會包含用戶數量、響應時間、持續時長。例如聚合支付接口，請求高峰出現在中午12點到1點午餐時間，持續時長大概1個小時，對并發量的需求描述就可以按照500用戶并發數，持續1小時，事務平均響應時間小于1秒來寫。
7. 易用性
即接口對第三方來說容易讀懂、容易使用，有基礎開發背景知識的開發工程師就可以很方便的調用成功。通常接口類產品的易用性都是通過SDK（軟件開發工具包，把接口封裝成JAVA或PHP等語言的調用函數）和調用DEMO（示例代碼）來實現，產品經理可以提出接口需要提供配套SDK（JAVA版本或PHP版本等）及調用DEMO的需求描述。
8. 其他
除了上述需求，還有一些不常用的業務需求產品經理可以關注，根據實際情況來判斷是否需要寫，例如系統每秒鐘能夠處理的事務數量（即TPS，系統吞吐量）需求；穩定性需求，即長時間運行一個比較大的并發量，觀察系統是否穩定不宕機。
對外系統接口中產品經理還會關注主動推送接口（主動給第三方發送信息）和被動推送接口（被第三方推送信息），這兩種接口的設計方法和上面所提的方法大體相同，但上面提到的都是非批量模式，這兩種接口的需求需要體現推送是批量方式還是單次方式，例如給監管機構上報數據的接口就采用了主動推送、批量上報的模式，產品經理需要定義清楚上報內容，上報頻次，上報異常處理方式。
本文由 @產品工具箱 原創發布于人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基于CC0協議。
