Passport SDK的設計與技術(shù)細節(jié)實例分析

　　58 趕集集團旗下?lián)碛卸鄠€ App，且全部使用同一套賬號體系，通過 Passport 部門提供的接口進行通信。經(jīng)過多年迭代，各個 App 中關于 Passport 的功能均出現(xiàn)了一些流程和接口上的差異。為了提高賬號安全，統(tǒng)一服務接口和流程，提高用戶體驗，由此決定開發(fā)了一個 Passport SDK，以集成 Passport 的相關功能，并提供給集團內(nèi)各業(yè)務 App 使用。

　　在項目開始之初，我們在公司內(nèi)經(jīng)過調(diào)研發(fā)現(xiàn)在使用 SDK 時，大家最關心的問題就是 SDK 使用起來是否簡單，即接口是否簡單、調(diào)用流程是否簡單、迭代升級是否簡單?；谶@幾個關鍵問題，我們把設計目標定為：將原本 Passport 功能中繁瑣的流程變成 Passport SDK 中簡單的功能調(diào)用和結(jié)果處理，讓使用 Passport 功能的開發(fā)者不再需要關心那些數(shù)量龐大而又無關緊要的部分，取而代之的是享有一個非常良好的開發(fā)體驗。由此，我們將設計原則定為：

　　接口要精簡；

　　服務的流程要黑盒；

　　無感知的迭代升級。

　　確定了設計原則后，下一步就是明確核心需求。Passport SDK 旨在為 58 同城賬號體系下的用戶提供通用的登錄相關服務頁面和接口。所以我們的 SDK 核心需求是提供服務，即通用服務頁面和通用服務接口，并在用戶調(diào)用服務后返回其結(jié)果。

　　設計簡單且有效的接口

　　首先我們從需求上明確接口有哪些？答案是數(shù)據(jù)接口與服務接口，具體如下：

　　數(shù)據(jù)接口是一些零散的數(shù)據(jù)存取操作，實際上無法做出太多的精簡。

　　服務接口包括各種服務頁面的調(diào)起和服務接口的調(diào)用：在服務頁面中，App 用戶與服務頁面的交互會觸發(fā)對應的業(yè)務事件；在服務接口中，會直接觸發(fā)對應的業(yè)務事件。

　　它們有一些共同點，比如都是主動發(fā)起的服務，都有各自的回調(diào)方法，大部分都需要可選或必選參數(shù)。

　　按照正常的設計模式，每個服務頁面和服務接口都可以設計為單獨的一個接口。但是因為 Passport 提供了數(shù)量眾多的服務，這種設計會造成大量接口的出現(xiàn)，從而增加 SDK 的接入與維護成本。因此在接口的設計上，必須做減法。

　　Passport SDK 的服務接口采用了集中式接口，我們把所有的服務頁面和服務接口抽象成服務類型。其中，每個服務類型代表一種服務，有自己的參數(shù)傳遞規(guī)則，有對應的回調(diào)方法。

　　如圖 1 所示，我們使用了接口路由的方法，在接口模塊內(nèi)置了一個路由表，決定服務類型和對應服務（通用服務頁面和通用服務接口）的映射。

　　圖 1 Passport SDK 服務接口設置

　　用戶只需在這個服務接口里傳入服務類型和符合規(guī)則的參數(shù)即可調(diào)用對應服務。服務完成后，會通過服務類型對應的回調(diào)方法傳遞結(jié)果：

　　簡單的接口設計會降低接入工作的成本，并使用戶獲得極好的接入體驗。

　　58 趕集集團旗下?lián)碛卸鄠€ App，且全部使用同一套賬號體系，通過 Passport 部門提供的接口進行通信。經(jīng)過多年迭代，各個 App 中關于 Passport 的功能均出現(xiàn)了一些流程和接口上的差異。為了提高賬號安全，統(tǒng)一服務接口和流程，提高用戶體驗，由此決定開發(fā)了一個 Passport SDK，以集成 Passport 的相關功能，并提供給集團內(nèi)各業(yè)務 App 使用。

　　在項目開始之初，我們在公司內(nèi)經(jīng)過調(diào)研發(fā)現(xiàn)在使用 SDK 時，大家最關心的問題就是 SDK 使用起來是否簡單，即接口是否簡單、調(diào)用流程是否簡單、迭代升級是否簡單。基于這幾個關鍵問題，我們把設計目標定為：將原本 Passport 功能中繁瑣的流程變成 Passport SDK 中簡單的功能調(diào)用和結(jié)果處理，讓使用 Passport 功能的開發(fā)者不再需要關心那些數(shù)量龐大而又無關緊要的部分，取而代之的是享有一個非常良好的開發(fā)體驗。由此，我們將設計原則定為：

　　接口要精簡；

　　服務的流程要黑盒；

　　無感知的迭代升級。

　　確定了設計原則后，下一步就是明確核心需求。Passport SDK 旨在為 58 同城賬號體系下的用戶提供通用的登錄相關服務頁面和接口。所以我們的 SDK 核心需求是提供服務，即通用服務頁面和通用服務接口，并在用戶調(diào)用服務后返回其結(jié)果。

　　設計簡單且有效的接口

　　首先我們從需求上明確接口有哪些？答案是數(shù)據(jù)接口與服務接口，具體如下：

　　數(shù)據(jù)接口是一些零散的數(shù)據(jù)存取操作，實際上無法做出太多的精簡。

　　服務接口包括各種服務頁面的調(diào)起和服務接口的調(diào)用：在服務頁面中，App 用戶與服務頁面的交互會觸發(fā)對應的業(yè)務事件；在服務接口中，會直接觸發(fā)對應的業(yè)務事件。

　　它們有一些共同點，比如都是主動發(fā)起的服務，都有各自的回調(diào)方法，大部分都需要可選或必選參數(shù)。

　　按照正常的設計模式，每個服務頁面和服務接口都可以設計為單獨的一個接口。但是因為 Passport 提供了數(shù)量眾多的服務，這種設計會造成大量接口的出現(xiàn)，從而增加 SDK 的接入與維護成本。因此在接口的設計上，必須做減法。

　　Passport SDK 的服務接口采用了集中式接口，我們把所有的服務頁面和服務接口抽象成服務類型。其中，每個服務類型代表一種服務，有自己的參數(shù)傳遞規(guī)則，有對應的回調(diào)方法。

　　如圖 1 所示，我們使用了接口路由的方法，在接口模塊內(nèi)置了一個路由表，決定服務類型和對應服務（通用服務頁面和通用服務接口）的映射。

　　圖 1 Passport SDK 服務接口設置

　　用戶只需在這個服務接口里傳入服務類型和符合規(guī)則的參數(shù)即可調(diào)用對應服務。服務完成后，會通過服務類型對應的回調(diào)方法傳遞結(jié)果：

　　簡單的接口設計會降低接入工作的成本，并使用戶獲得極好的接入體驗。