大家都談 OpenData 那麼久了，也該是來聊聊 OpenAPI 才對。 這場演講會利用現在台灣佔有率蠻高的企業內部服務 (外部：Library) 及企業即時通訊軟體 (內部：OpenAPI) 為展示，讓大家了解如何讓老舊的網路服務也能 Open 出來。 最後會再分享一下什麼是 WebHooks，以及如何實作及要注意的細節。期許之後大家所開發的網路服務不只能夠接收外部資料 (OpenAPI)，也能即時提供內部資料給外部服務 (WebHooks)。

1. 如何利用 OpenAPI 及 WebHooks
讓老舊的網路服務也可程式化
Kewang

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

4. 4
Agenda
● OpenData
● OpenAPI
● WebHooks

5. 5
OpenData

6. 6
Availability and Access

7. 7
Availability and Access
●
資料必須完整釋出

8. 8
Availability and Access
●
資料必須完整釋出
●
只能依照再製的成本徵收適當的費用

9. 9
Availability and Access
●
資料必須完整釋出
●
只能依照再製的成本徵收適當的費用
●
最好能提供網路下載

10. 10
Availability and Access
●
資料必須完整釋出
●
只能依照再製的成本徵收適當的費用
●
最好能提供網路下載
●
提供的資料格式必須是適用和可被修改的

11. 11
Re-use and Redistribution

12. 12
Re-use and Redistribution
●
資料釋出時必須採用允許資料的重新使用和散播
的授權聲明

13. 13
Re-use and Redistribution
●
資料釋出時必須採用允許資料的重新使用和散播
的授權聲明
●
允許與其他資料混合使用

14. 14
Universal Participation

15. 15
Universal Participation
●
任何人都可使用，重新使用和散佈這些資料

16. 16
Universal Participation
●
任何人都可使用，重新使用和散佈這些資料
●
不能限制資料使用的範圍，或是使用者的資格

17. 17
可互通性
interoperability

18. 18
可互通性 - interoperability

19. 19
可互通性 - interoperability
● 不同的系統與組織可以共同運作 (inter-operate)
的能力

20. 20
可互通性 - interoperability
● 不同的系統與組織可以共同運作 (inter-operate)
的能力
● 讓不同的資料集 (datasets) 可以彼此引用或是相
互混用的能力

21. 21
OpenData

22. 22
OpenData

23. 23
OpenAPI
OpenData

24. 24
OpenAPI

25. 25
OpenAPI
政府

26. 26
唐鳳對於 OpenAPI 的看法 - 1

27. 27
唐鳳對於 OpenAPI 的看法 - 1
● 自動發現 - API Discovery

28. 28
唐鳳對於 OpenAPI 的看法 - 1
● 自動發現 - API Discovery
● metadata 包含網站上所有機器可讀的部分放在哪
裡、用什麼方式可以自動界接

29. 29
唐鳳對於 OpenAPI 的看法 - 1
● 自動發現 - API Discovery
● metadata 包含網站上所有機器可讀的部分放在哪
裡、用什麼方式可以自動界接
●
寫一支程式就能把所有公務機關網站處理好

30. 30
唐鳳對於 OpenAPI 的看法 - 2

31. 31
唐鳳對於 OpenAPI 的看法 - 2
●
機器可寫入，目前階段只有做到機器可讀

32. 32
唐鳳對於 OpenAPI 的看法 - 2
●
機器可寫入，目前階段只有做到機器可讀
●
公務體系除非一開始就約定好要用完全相同的結
構資料，不然很難做到跨機關的界接

33. 33
唐鳳對於 OpenAPI 的看法 - 2
●
機器可寫入，目前階段只有做到機器可讀
●
公務體系除非一開始就約定好要用完全相同的結
構資料，不然很難做到跨機關的界接
●
簽公文、報稅時，不一定得用原廠商設計的介面

34. 34
唐鳳對於 OpenAPI 的看法 - 2
●
機器可寫入，目前階段只有做到機器可讀
●
公務體系除非一開始就約定好要用完全相同的結
構資料，不然很難做到跨機關的界接
●
簽公文、報稅時，不一定得用原廠商設計的介面
●
當新載具出現時，可以接到機器可寫入的端口，
不需要全部重寫一遍

35. 35
唐鳳對於 OpenAPI 的看法 - 2
●
機器可寫入，目前階段只有做到機器可讀
●
公務體系除非一開始就約定好要用完全相同的結
構資料，不然很難做到跨機關的界接
●
簽公文、報稅時，不一定得用原廠商設計的介面
●
當新載具出現時，可以接到機器可寫入的端口，
不需要全部重寫一遍
●
當每個系統都具備機器可寫入的概念，就能通通
界接到同一地方，做各式各樣的應用

36. 36
我的補充

37. 37
我的補充
● 公文系統： MSON, git, GPG key

38. 38
我的補充
● 公文系統： MSON, git, GPG key
– MSON DSL ：對公文格式標準化

39. 39
我的補充
● 公文系統： MSON, git, GPG key
– MSON DSL ：對公文格式標準化
– git, GPG key ：保證不被竄改

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 ：讓各家廠商深度整合自家服務

43. 43
Live DEMO

44. 44
OpenAPI

45. 45
OpenAPI
個人

46. 46
OpenAPI 實作

47. 47
OpenAPI 實作
● 把 OpenData 做成 Library

48. 48
OpenAPI 實作
● 把 OpenData 做成 Library
● 把 OpenData 用 agent 拉回 server ，轉成 OpenAPI

49. 49
OpenAPI 實作
● 把 OpenData 做成 Library
● 把 OpenData 用 agent 拉回 server ，轉成 OpenAPI
● 把網路服務的內部 API 轉為 OpenAPI

50. 50
1

51. 51
OpenData
1

52. 52
OpenData
1

53. 53
Library
OpenData
1

54. 54
以 tw.kewang.cwb 為例

55. 55
以 tw.kewang.cwb 為例
● 申請 APIKEY

56. 56
以 tw.kewang.cwb 為例
● 申請 APIKEY
● 了解 data schema

57. 57
以 tw.kewang.cwb 為例
● 申請 APIKEY
● 了解 data schema
●
回傳原始格式及易用格式

58. 58
以 tw.kewang.cwb 為例
● 申請 APIKEY
● 了解 data schema
●
回傳原始格式及易用格式
● 使用 SemVer 定義版號

59. 59
以 tw.kewang.cwb 為例
● 申請 APIKEY
● 了解 data schema
●
回傳原始格式及易用格式
● 使用 SemVer 定義版號
● 使用 GitHub 管理

60. 60
以 tw.kewang.cwb 為例
● 申請 APIKEY
● 了解 data schema
●
回傳原始格式及易用格式
● 使用 SemVer 定義版號
● 使用 GitHub 管理
● 撰寫 JavaDoc

61. 61
以 tw.kewang.cwb 為例
● 申請 APIKEY
● 了解 data schema
●
回傳原始格式及易用格式
● 使用 SemVer 定義版號
● 使用 GitHub 管理
● 撰寫 JavaDoc
● 上傳到 Maven Central

62. 62
缺點

63. 63
缺點
● 沒有 API 可用

64. 64
缺點
● 沒有 API 可用
● 需要為每個程式語言都寫一個 Library

65. 65
缺點
● 沒有 API 可用
● 需要為每個程式語言都寫一個 Library
● vendor 變更 data schema 時無法立即得知

66. 66
Live DEMO

67. 67
2

68. 68
OpenData
2

69. 69
OpenData
1
1
2

70. 70
agent
OpenData
2
1

71. 71
agent
OpenData
2
1
2

72. 72
agent
OpenData
server
2
1
2

73. 73
agent
OpenData
server
1
2
2
3

74. 74
agent
OpenData
server
OpenAPI
2
1
2
3

75. 75
實作方式

76. 76
實作方式
● agent 定時取得 OpenData 並將其存至 server 內

77. 77
實作方式
● agent 定時取得 OpenData 並將其存至 server 內
● server 提供 OpenAPI 給開發者使用

78. 78
實作方式
● agent 定時取得 OpenData 並將其存至 server 內
● server 提供 OpenAPI 給開發者使用
● 使用 APIKEY 管理

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 文件

82. 82
優點

83. 83
優點
● APIKEY

84. 84
優點
● APIKEY
– 紀錄使用量、來源

85. 85
優點
● APIKEY
– 紀錄使用量、來源
– 限制使用量、來源

86. 86
優點
● APIKEY
– 紀錄使用量、來源
– 限制使用量、來源
● 不怕 vendor 變更 data schema

87. 87
優點
● APIKEY
– 紀錄使用量、來源
– 限制使用量、來源
● 不怕 vendor 變更 data schema
– 變更時 agent 會 parse 失敗，就不會上傳到 server

88. 88
缺點

89. 89
缺點
● 定時不間斷取得 OpenData 易被誤認 DDoS

90. 90
缺點
● 定時不間斷取得 OpenData 易被誤認 DDoS
● 無法完全即時更新 OpenData

91. 91
NO Live DEMO

92. 92
3

93. 93
Internal API
3

94. 94
Internal API
3

95. 95
Adapter
Internal API
3

96. 96
Adapter
Internal API
3

97. 97
Adapter
Internal API
OpenAPI 3

98. 98
實作方式

99. 99
實作方式
● 使用 Adapter 將 OpenAPI 及 Internal API 互轉

100. 100
實作方式
● 使用 Adapter 將 OpenAPI 及 Internal API 互轉
● 使用 APIKEY 管理

101. 101
實作方式
● 使用 Adapter 將 OpenAPI 及 Internal API 互轉
● 使用 APIKEY 管理
● 使用 middleware 將 APIKEY 轉換回 Internal API

102. 102
實作方式
● 使用 Adapter 將 OpenAPI 及 Internal API 互轉
● 使用 APIKEY 管理
● 使用 middleware 將 APIKEY 轉換回 Internal API
● 撰寫 API 文件

103. 103
優點

104. 104
優點
● Adapter

105. 105
優點
● Adapter
– Internal API 及 OpenAPI 的 request 及 response 欄位不
同，使用 Adapter 將兩者做轉換

106. 106
優點
● Adapter
– Internal API 及 OpenAPI 的 request 及 response 欄位不
同，使用 Adapter 將兩者做轉換
● APIKEY

107. 107
優點
● Adapter
– Internal API 及 OpenAPI 的 request 及 response 欄位不
同，使用 Adapter 將兩者做轉換
● APIKEY
– 取代帳號密碼，保障敏感資料不外洩

108. 108
優點
● Adapter
– Internal API 及 OpenAPI 的 request 及 response 欄位不
同，使用 Adapter 將兩者做轉換
● APIKEY
– 取代帳號密碼，保障敏感資料不外洩
● 撰寫 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

111. 111
Live DEMO

112. 112
WebHooks
https://webhooks.kewang.tw

113. 113
client

114. 114
1
client

115. 115
server
1
client

116. 116
server
1
client
2

117. 117
server
1
client
2
2'

118. 118
server
1 vendor
client
2
2'

119. 119
實作方式 - POST action

120. 120
實作方式 - POST action
● 將 server 的 request 及 response 重新使用 POST
轉發到 vendor

121. 121
實作方式 - 獨立 thread

122. 122
實作方式 - 獨立 thread
● 避免影響原 API 運作

123. 123
實作方式 - 獨立 thread
● 避免影響原 API 運作
● 在 middleware 新開 thread 或丟到 MQ 執行

124. 124
實作方式 - 使用 SSL

125. 125
實作方式 - 使用 SSL
● �vendor 不使用 SSL

126. 126
實作方式 - 使用 SSL
● �vendor 不使用 SSL
● �vendor 使用自簽憑證

127. 127
實作方式 - 使用 SSL
● �vendor 不使用 SSL
● �vendor 使用自簽憑證
● �vendor 使用合法憑證

128. 128
實作方式 - request token

129. 129
實作方式 - request token
● server 將資料傳送至 vendor 前，將雙方約定好的
token 放在 header 中再傳送

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 相同
– 相同：資料未被竄改
– 不相同：資料被竄改

133. 133
實作方式 - HMAC-SHA256

134. 134
實作方式 - HMAC-SHA256
● 將要傳送的資料使用 server 及 vendor 約定好的
token 計算出 HMAC-SHA256(H1)

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 相同
– 相同：資料未被竄改
– 不相同：資料被竄改

140. 140
實作方式 - 相同 data schema

141. 141
實作方式 - 相同 data schema
● 必須與 OpenAPI 的 data schema 相同

142. 142
Live DEMO

143. 143
Summary

144. 144
Summary

145. 145
Summary
● OpenAPI

146. 146
Summary
● OpenAPI
– 清楚的文件

147. 147
Summary
● OpenAPI
– 清楚的文件
– 認證：別帶帳密，改用 token

148. 148
Summary
● OpenAPI
– 清楚的文件
– 認證：別帶帳密，改用 token
– 用 middleware

149. 149
Summary
● OpenAPI
– 清楚的文件
– 認證：別帶帳密，改用 token
– 用 middleware
● WebHooks

150. 150
Summary
● OpenAPI
– 清楚的文件
– 認證：別帶帳密，改用 token
– 用 middleware
● WebHooks
– 清楚的文件

151. 151
Summary
● OpenAPI
– 清楚的文件
– 認證：別帶帳密，改用 token
– 用 middleware
● WebHooks
– 清楚的文件
– 獨立 thread 運作

152. 152
Summary
● OpenAPI
– 清楚的文件
– 認證：別帶帳密，改用 token
– 用 middleware
● WebHooks
– 清楚的文件
– 獨立 thread 運作
– 驗證來源是否合法

153. 153
Summary - 潛在服務

154. 154
Summary - 潛在服務
●
工時系統

155. 155
Summary - 潛在服務
●
工時系統
●
日報系統

156. 156
Summary - 潛在服務
●
工時系統
●
日報系統
● CRM

157. 157
Summary - 潛在服務
●
工時系統
●
日報系統
● CRM
● ERP

158. 158
References
●
什麼是開放資料？
●
2017-03-22 共通性應用程式介面開放規範研議
●
數位政委唐鳳：Open Data只是基礎，下個發展目標
是Open API
●
對於公文系統的建議
●
刷綜所稅系統的存在感
● rest - Best practices for API versioning? - Stack Ove
rflow
● Verifying requests from Slack | Slack

159. 159

160. 160
● iOS
● Android
● Backend
● Hadoop