[設計]-OpenAPI中的callback機制

聽老歌

轉(zhuǎn)：cloudxman

[設計]-OpenAPI中的callback機制

OpenAPI提供給外部網(wǎng)站訪問，為了便于討論，我們把接口提供方定義為Resource Provider，簡稱RP，使用方定義為Caller。 通常而言，我們在OpenAPI的設計原則中，要求Caller到RP是必須是單向訪問的，只有這樣，才能解除兩個網(wǎng)站的雙向耦合。但是實際中，有時候還真存在需求，不得不讓RP訪問到Caller，我們把這個情況叫Callback。我想舉兩個例子來說明這種情況。 網(wǎng)上銀行支付 做過支付寶支付的都清楚，商家扣款必須把調(diào)用發(fā)到支付寶（RP），但是這筆支付究竟是否成功，需要支付寶回調(diào)來確認，以及支持成功后最終返回到一個支付成功的展示界面。在這個場景中，就用到了callback機制。 跨網(wǎng)站的好友確認 網(wǎng)站A和網(wǎng)站B深度合作，網(wǎng)站A的用戶可以加網(wǎng)站B的用戶為好友。假設網(wǎng)站A發(fā)起一個到網(wǎng)站B OpenAPI的call, call的url大致是：api.do?method=addFriend&a_uid=1234&b_uid=4321。 但是，我們知道，通常一個網(wǎng)站的加好友是必須經(jīng)過對方確認的，這樣麻煩就來了。這個請求發(fā)送后，并不知道這個b_uid是否接受，也不知道什么時候接受？所以，就必須設計一個callback的機制，讓RP回調(diào)caller，解決這類異步的確認問題。 好了，有了上面兩個引子，我們可以討論OpenAPI的callback機制了。 在編程語言中，其實很早就存在callback的做法了。比如在C語言中，通常是把一個函數(shù)指針作為參數(shù)傳入到某個method內(nèi)部，只要確保這個函數(shù)指針的生命周期在回調(diào)的時候還存在，即可執(zhí)行。對于OpenAPI其實也一樣。我們可以設想，在OpenAPI的傳入?yún)��?shù)中引入callback_url, 來讓RP回調(diào).   值得補充的是，光有一個callback_url 參數(shù)是不太夠的。為什么呢？ method + callback_url 只能表達一個method對應一個callback,  如果一個method有多個callback呢，就需要額外的參數(shù)來表達。所以，建議可以在引入一個 callback_type 的參數(shù)。RP在拿到（method, callback_type)后可以根據(jù)callback_type來判斷是什么情況，從而進行不同的處理，然后進行回調(diào)。 很多時候，RP并不會在caller調(diào)用后立即callback，而是需要等待內(nèi)部某些事件發(fā)生的時候才callback。這樣RP內(nèi)部就需要把這些callback需求存儲下來。 接下來討論一個問題，callback_url如果需要一些參數(shù)怎么辦？比如在加好友的這個例子中，B網(wǎng)站的用戶確認好友關系后，還需要在發(fā)起callback_url調(diào)用時把a_uid和b_uid告訴網(wǎng)站A.  當然，這就回到了網(wǎng)站A的OpenAPI規(guī)范了。這個問題很好解決，只是引申出來，對于OpenAPI的規(guī)劃，并不是接口包裝那么容易，需要考慮到很多因素。也反映了我們?yōu)槭裁匆恢碧岬降囊粋�設計原則：盡量單向依賴

macbook3

還不錯嘛MFC界面