系統型產品接口設計方法總結
文章簡單總結了接口設計的一些方法,希望能夠對你有所幫助。
現在社會都在將談論“共享”,很多我們接觸的APP中,要完成所有的業務流程多少都需要和第三方產品進行對接,使用第三方已完成的功能。
舉個簡單的例子:現在幾乎所有的APP注冊都是使用手機號進行注冊,為了驗證手機號為操作人本人所使用,都會發送一條短信驗證碼。這個時候,基本上發送短信的業務就使用到了第三方短信平臺來完成。所以作為產品經理必須要了解,如何進行對接,要傳什么信息給第三方平臺,第三方平臺處理完成業務后,所返回的信息我們應該如何處理等。
在此,我就簡單的做個總結,讓各位剛入行的產品經理們知道如何進行多系統對接。首先,從了解基本名稱出發;其次,了解設計的方法;最后案例解說加深大家的理解。
一、了解名詞及作用
1.?? 名詞解釋
- 軟件接口:程序組件間對接的出入口。
- 頁面跳轉同步通知:如果一個進程在執行請求時,該請求需要一段時間才能返回信息,那么這個進程就會一直等待下去。通俗點就是有先后順序,必須先完成前面事務才能做后面事務。
- 異步通知:進程不用等待可以繼續執行下面的操作。背后信息傳輸,不分先后。
2.?? 接口作用
由架構師將整個系統架構搭建出來,各個子系統或者各個模塊之間通過接口進行調用,可以讓整個系統拓展性增強。
各個子系統或各模塊之間信息傳輸必須要進行一定的安全驗證,保證信息傳輸的正確性。
3.?? 接口的組成
接口常常成對出現,有請求參數和返回參數。
請求接口一般必須包括兩個部分:基本參數、業務參數
- 基本參數:接口名稱、身份認證參數(即對接的模塊或系統ID、簽名、密鑰等)
- 業務參數:該接口所有提供的服務或者所要達到目標的業務信息。
4.?? 同步、異步一般傳值情況
同步:主要作用于頁面跳轉,傳值信息主要將頁面所要處理的最關鍵信息傳輸即可。
異步:是為了強調給對接的模塊處理業務信息,傳值信息根據實際情況盡可能詳細一些,但是必須和本接口設計的目標一致,不要傳輸太多無用的參數。
二、設計的方法及選擇
1.?? 接口設計的方法
第一種:外部調用方call本系統的接口,同步返回請求成功,但實際操作是本系統延后去執行的,異步返回處理結果。
- 發起方:用戶
- 優點:外部調用方不需要等待業務處理結果,可以進行自身其實業務處理。
- 不足:當外部調用方未能及時處理異步通知結果時,有可能會導致自身業務會存在一些風險或用戶體驗度不足。為減輕不足之處,此方式的接口設計,需要另外再設計一個查詢業務處理結果的接口。
第二種:外部調用方call本系統的接口,業務處理完成后直接返回處理結果。
- 發起方:商戶/外部調用方
- 優點:外部調用方必須等到本系統業務處理完成后才能繼續進行自身系統的業務,可以避免存在遺漏的業務未處理。
- 缺點:外部調用方必須等待業務處理結果,前臺用戶也會看到等待頁面,增加了用戶的焦躁感。
2.?? 接口設計方式的選擇
接口要為需求服務,在接口設計時的思考步驟:
- 回歸產品的最初定位
- 設想業務場景,選擇最優的用戶體驗方式。
- 根據最優的用戶體驗方式繪制業務流程。
3.?? 示例-廣電公共賬戶充值
3.1.需求描述
- 為SP提供廣電公共賬戶充值服務,該服務屬于獨立的功能模塊。
- 用戶進行業務訂購,當公共賬戶余額不足時,需要充值賬戶余額后進行訂購。
3.2.分析思路
1.定位:充值服務、獨立功能模塊。
2.場景設想:
3.場景選擇:通過以上場景設想描述分析得出,場景二對于用戶來說操作步驟會比較簡單,可以最快的達到最初的需求目標。
4.接口設計方式選擇:第二種方式
3.3.繪制業務流程
總結
在進行多產品系統對接時,在接口設計方法各有優劣勢,采用何種方法進行設計最終還得回歸到產品的特性,需考慮到產品運行的環境、產品定位、使用場景、團隊技術水平情況等多方面考慮,去選擇合適自身產品的方法。
作者:嵐天,一位從前端開發轉入產品崗的初級產品經理
本文由 @嵐天 原創發布于人人都是產品經理。未經許可,禁止轉載。
題圖來自PEXELS,基于CC0協議
3.3繪制業務流程中
表述可能不準確,支付處理這一段,應該是從SP和樂眾支付之間的調用返回?
不知道這樣理解準確嗎
產品經理搞接口就是不歸路,提好需求,丟給架構師吧。不然搞到最后,產品寫的都是接口文檔,架構師在笑。
不能同意更多,之前去傳統企業給移動做系統,妹的,北京總部的產品只做業務描述,我們成都的產品還要弄接口文檔,用戶自己業務都不確定,傳統軟件企業真是該被淘汰,產品界面丑,交互復雜,一點都不考慮用戶體驗,只為項目驗收,而項目就是為了給領導看,實際都不用的功能。
同意,深有感受!
實用!