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

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

　　接口要精簡；

　　服務(wù)的流程要黑盒；

　　無感知的迭代升級。

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

　　設(shè)計簡單且有效的接口

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

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

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

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

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

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

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

　　圖 1 Passport SDK 服務(wù)接口設(shè)置

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

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

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

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

　　接口要精簡；

　　服務(wù)的流程要黑盒；

　　無感知的迭代升級。

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

　　設(shè)計簡單且有效的接口

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

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

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

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

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

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

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

　　圖 1 Passport SDK 服務(wù)接口設(shè)置

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

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