關於Open API的想法 | 文章 – 滙豐機滙

近年各行各業也大推Open API,香港各大銀行在金管局牽頭下也陸續推出,提供更多service 供外部開發者使用。筆者很贊成Open API的想法,唯對目前的實施方法和成果並不太樂觀。

科技  ·    ·  2 mins read

近年各行各業也大推Open API,香港各大銀行在金管局牽頭下也陸續推出,提供更多service 供外部開發者使用。筆者很贊成Open API的想法,唯對目前的實施方法和成果並不太樂觀。

傳統銀行業的內部系統通常以業務作為單位,存款貸款理財投資各有獨立系統支持,本身就算內部各系統互通訊息都需要獨立建接口,Interface 也隨個別系統而定,少有統一制式,多數也只是做到多渠道共享同一接口,或用ESB將接口盡量統一。

以這樣的背景推進Open API,可以預期的是能夠開放的API將受限於產品平台現有能支援的接口,結果很大機會是在現有網銀及APP外新增多一個渠道。另外由於每個接口需要重新思考access control及authentication,又要照顧performance,初期只支持一些查詢功能,或提供static information,實際用途不大,成本效益就更低了。

筆者認為要推行Open API,機構內部亦需要很大程度提升現有各大平台的API 管理及服務範圍,甚至應更進一步推進升級為以Web Services形式提供服務,以更便於與外部開發者共享同一套API。

以Amazon 為例 (當然這是最好的例子),今天我們都知道Amazon 內部系統通訊全部都經由Web Services進行,這全是基於Amazon 在很多年前開始推行的改變。無論任何一個業務組,其轄下功能和資料都必須提供Web Services共享,業務之間只能通過Web Services交流,不得經由其它途徑,不容許共享內存,更不容許後門程式。各業務組亦需要負責為功能寫documentation,目標就是日後能直接將服務公開,而服務亦終於在2006年以Amazon Web Services (AWS)為名推出市場,當中不少服務容許介面操作同時亦容許API調用,對開發人員極為方便。

回望今天銀行業以及很多的大型機構,內部系統按業務需要而採購,系統多以照顧業務本身運作流程而設,本身並不太考慮對外對接,因此業務需求亦多以滿足介面操作為先,只有在需要時考慮提供調用接口,要提供 Open API 就更為不便。

要像Amazon 般全面更換成Web Services的話,牽涉到可能要重寫大部份系統,成本基本上沒可能做得到合理,較為合理的方法反而是建立API management layer,以不大幅影響後台產品系統架構為前提,盡量開發更多接口,集中管理。以這種思路發展,API management 亦可自成獨立系統,除處理像ESB的功能,亦管理authentication,處理分流等。API management platform也可以有lifecycle management,容許backward compatible,在多渠道多產品的環境就更為適合了。

面向未來,銀行亦應更為走向發展作為基建,提供更方便的途徑供各行各業及個人使用,Open API 絕對是在走對的一步。

Dennis Ng
Dennis Ng
Dennis Ng
Dennis Ng