Contenu connexe
Similaire à 如何利用 OpenAPI 及 WebHooks 讓老舊的網路服務也可程式化 (20)
Plus de Mu Chun Wang (20)
如何利用 OpenAPI 及 WebHooks 讓老舊的網路服務也可程式化
- 2. Who I am
● 王慕羣 Kewang
● Java / PHP / Node.js / AngularJS
● HBase / SQL-like
● Git / DevOps
●
熱愛開源
GitHubGitHub kewangkewang
LinkedinLinkedin kewangtwkewangtw
SlideShareSlideShare kewangkewang
GmailGmail cpckewangcpckewang
FacebookFacebook Kewang 的資訊進化論Kewang 的資訊進化論
JCConfJCConf '16 '17'16 '17
HadoopConHadoopCon '14 '15'14 '15
MOPCONMOPCON '14'14
DevOpsDays TaipeiDevOpsDays Taipei '17'17
- 3. What Mitake is
三竹資訊
● Qmi:企業內部即時通訊軟體
●
全國最大的企業簡訊平台
● 市佔近 100% 的行動下單
● 市佔近 70% 的行動銀行
●
企業內部應用、產壽險、金融相關政府機關
● 行動股市、三竹小股王、台灣匯率、 MicroCoin 、兌彩券
GitHubGitHub mitaketwmitaketw
- 29. 29
唐鳳對於 OpenAPI 的看法 - 1
● 自動發現 - API Discovery
● metadata 包含網站上所有機器可讀的部分放在哪
裡、用什麼方式可以自動界接
●
寫一支程式就能把所有公務機關網站處理好
- 33. 33
唐鳳對於 OpenAPI 的看法 - 2
●
機器可寫入,目前階段只有做到機器可讀
●
公務體系除非一開始就約定好要用完全相同的結
構資料,不然很難做到跨機關的界接
●
簽公文、報稅時,不一定得用原廠商設計的介面
- 34. 34
唐鳳對於 OpenAPI 的看法 - 2
●
機器可寫入,目前階段只有做到機器可讀
●
公務體系除非一開始就約定好要用完全相同的結
構資料,不然很難做到跨機關的界接
●
簽公文、報稅時,不一定得用原廠商設計的介面
●
當新載具出現時,可以接到機器可寫入的端口,
不需要全部重寫一遍
- 35. 35
唐鳳對於 OpenAPI 的看法 - 2
●
機器可寫入,目前階段只有做到機器可讀
●
公務體系除非一開始就約定好要用完全相同的結
構資料,不然很難做到跨機關的界接
●
簽公文、報稅時,不一定得用原廠商設計的介面
●
當新載具出現時,可以接到機器可寫入的端口,
不需要全部重寫一遍
●
當每個系統都具備機器可寫入的概念,就能通通
界接到同一地方,做各式各樣的應用
- 40. 40
我的補充
● 公文系統: MSON, git, GPG key
– MSON DSL :對公文格式標準化
– git, GPG key :保證不被竄改
● 報稅系統: Chrome Extension, OpenAPI
- 41. 41
我的補充
● 公文系統: MSON, git, GPG key
– MSON DSL :對公文格式標準化
– git, GPG key :保證不被竄改
● 報稅系統: Chrome Extension, OpenAPI
– Chrome Extension :強化報稅體驗
- 42. 42
我的補充
● 公文系統: MSON, git, GPG key
– MSON DSL :對公文格式標準化
– git, GPG key :保證不被竄改
● 報稅系統: Chrome Extension, OpenAPI
– Chrome Extension :強化報稅體驗
– OpenAPI :讓各家廠商深度整合自家服務
- 49. 49
OpenAPI 實作
● 把 OpenData 做成 Library
● 把 OpenData 用 agent 拉回 server ,轉成 OpenAPI
● 把網路服務的內部 API 轉為 OpenAPI
- 61. 61
以 tw.kewang.cwb 為例
● 申請 APIKEY
● 了解 data schema
●
回傳原始格式及易用格式
● 使用 SemVer 定義版號
● 使用 GitHub 管理
● 撰寫 JavaDoc
● 上傳到 Maven Central
- 65. 65
缺點
● 沒有 API 可用
● 需要為每個程式語言都寫一個 Library
● vendor 變更 data schema 時無法立即得知
- 79. 79
實作方式
● agent 定時取得 OpenData 並將其存至 server 內
● server 提供 OpenAPI 給開發者使用
● 使用 APIKEY 管理
● 了解 data schema
- 80. 80
實作方式
● agent 定時取得 OpenData 並將其存至 server 內
● server 提供 OpenAPI 給開發者使用
● 使用 APIKEY 管理
● 了解 data schema
● 規劃 API 版本
- 81. 81
實作方式
● agent 定時取得 OpenData 並將其存至 server 內
● server 提供 OpenAPI 給開發者使用
● 使用 APIKEY 管理
● 了解 data schema
● 規劃 API 版本
● 撰寫 API 文件
- 101. 101
實作方式
● 使用 Adapter 將 OpenAPI 及 Internal API 互轉
● 使用 APIKEY 管理
● 使用 middleware 將 APIKEY 轉換回 Internal API
- 102. 102
實作方式
● 使用 Adapter 將 OpenAPI 及 Internal API 互轉
● 使用 APIKEY 管理
● 使用 middleware 將 APIKEY 轉換回 Internal API
● 撰寫 API 文件
- 109. 109
優點
● Adapter
– Internal API 及 OpenAPI 的 request 及 response 欄位不
同,使用 Adapter 將兩者做轉換
● APIKEY
– 取代帳號密碼,保障敏感資料不外洩
● 撰寫 API 文件
– API Blueprint : Markdown, MSON
- 110. 110
優點
● Adapter
– Internal API 及 OpenAPI 的 request 及 response 欄位不
同,使用 Adapter 將兩者做轉換
● APIKEY
– 取代帳號密碼,保障敏感資料不外洩
● 撰寫 API 文件
– API Blueprint : Markdown, MSON
– Swagger : YAML, JSON
- 120. 120
實作方式 - POST action
● 將 server 的 request 及 response 重新使用 POST
轉發到 vendor
- 123. 123
實作方式 - 獨立 thread
● 避免影響原 API 運作
● 在 middleware 新開 thread 或丟到 MQ 執行
- 127. 127
實作方式 - 使用 SSL
● �vendor 不使用 SSL
● �vendor 使用自簽憑證
● �vendor 使用合法憑證
- 130. 130
實作方式 - request token
● server 將資料傳送至 vendor 前,將雙方約定好的
token 放在 header 中再傳送
● vendor 比較 header 是否與約定好的 token 相同
- 131. 131
實作方式 - request token
● server 將資料傳送至 vendor 前,將雙方約定好的
token 放在 header 中再傳送
● vendor 比較 header 是否與約定好的 token 相同
– 相同:資料未被竄改
- 132. 132
實作方式 - request token
● server 將資料傳送至 vendor 前,將雙方約定好的
token 放在 header 中再傳送
● vendor 比較 header 是否與約定好的 token 相同
– 相同:資料未被竄改
– 不相同:資料被竄改
- 135. 135
實作方式 - HMAC-SHA256
● 將要傳送的資料使用 server 及 vendor 約定好的
token 計算出 HMAC-SHA256(H1)
● server 將資料及 HMAC-SHA256 直接傳送至
vendor
- 136. 136
實作方式 - HMAC-SHA256
● 將要傳送的資料使用 server 及 vendor 約定好的
token 計算出 HMAC-SHA256(H1)
● server 將資料及 HMAC-SHA256 直接傳送至
vendor
● vendor 使用 token 將接收到的資料計算出 HMAC-
SHA256(H2)
- 137. 137
實作方式 - HMAC-SHA256
● 將要傳送的資料使用 server 及 vendor 約定好的
token 計算出 HMAC-SHA256(H1)
● server 將資料及 HMAC-SHA256 直接傳送至
vendor
● vendor 使用 token 將接收到的資料計算出 HMAC-
SHA256(H2)
● vendor 比較 H1 是否與 H2 相同
- 138. 138
實作方式 - HMAC-SHA256
● 將要傳送的資料使用 server 及 vendor 約定好的
token 計算出 HMAC-SHA256(H1)
● server 將資料及 HMAC-SHA256 直接傳送至
vendor
● vendor 使用 token 將接收到的資料計算出 HMAC-
SHA256(H2)
● vendor 比較 H1 是否與 H2 相同
– 相同:資料未被竄改
- 139. 139
實作方式 - HMAC-SHA256
● 將要傳送的資料使用 server 及 vendor 約定好的
token 計算出 HMAC-SHA256(H1)
● server 將資料及 HMAC-SHA256 直接傳送至
vendor
● vendor 使用 token 將接收到的資料計算出 HMAC-
SHA256(H2)
● vendor 比較 H1 是否與 H2 相同
– 相同:資料未被竄改
– 不相同:資料被竄改