📄️ 前言 - iThome鐵人賽佳作系列作
寫在前面
📄️ Day01 - 一切從試著了解開始
前言
📄️ Day02 - 盤點需求，準備環境與工具
在大致了解完永豐金APIs的兩大面向後，接下來要選擇與決定要使用什麼語言或工具來完成接下來的開發與串接。
📄️ Day03 - 分析技術文件後，開始做個Nonce開胃菜吧
接下來就從兩大主題豐收款消費支付API與Shioaji證券API之間，挑一個來進行，既然證券開盤時間在上班有點難研究Shioaji，不要把事情搞的太複雜，就順著感覺走，就先來研究豐收款消費支付API這個題目。
📄️ Day04 - 金流API的起手式，每次溝通都機密
昨天用了Postman先小試身手，從測試環境取得了必要的發語詞Nonce的值(還記得這個60秒就會過期了吧)，現在要來了解一下正式使用API溝通的時候會需要的一些流程。
📄️ Day05 - 繼續把加密這件事看下去
中秋連假還要寫鐵人賽的文章真的是有一點吃力，雖然平常也只有晚上下班後可以撰寫文章，但連假畢竟有較多需要和家人一起互動 的時間，要專注將心思放在文件撰寫與規格研究和測試上面，真的有一定的難度。
📄️ Day06 - 安全簽章簽下去，API呼叫沒在怕
在昨天講完了Message的密文產生細節流程後，回過頭來我再來談Sign安全簽章，我認為這順序比較容易理解。其實這整段API的呼叫，可分為幾個要素：
📄️ Day07 - 淺談binary與十六進位Hex、UTF-8文字編碼轉換
在進入正式叫用API前，還記得先前有比如四組Hash碼(以十六進位表示)，或者要轉成bytearray (二進位binary)處理，然後又要轉成字串，或者需要對utf-8進行編碼嗎？
📄️ Day08 - 十六進位格式的後續探討，字串傳輸容量倍增了
延續昨天的十六進位轉換，還有件重要的事。
📄️ Day09 - 安全無虞後，開始建立訂單 ATM虛擬帳號篇1
先前花了幾天的時間，終於把每次API發送前的安全規定的細碎精工給搞定了，也開了篇幅寫了一些關於十六進位轉換與Base64的差異等的小專題後，接下來就可以再回到使用情境面，來看我們身為商家角色要為我們的電商平台顧客提供怎麼樣的服務。
📄️ Day10 - 安全無虞後，開始建立訂單 ATM虛擬帳號篇2
目前的情境是，我們的顧客已在電商平台把商品放入購物車，而且最後在失心瘋加上手滑的情境下，決定要購買，因此這份訂單需要先行成立，後面的階段才是將此訂單實際付款狀態串起來。
📄️ Day11 - 禮尚往來，我們也需要解開API回傳的密秘
回顧昨天拿到的response，乍看之下以為API將我們傳給他的內容原封不動傳回來了。
📄️ Day12 - 為BackendURL中收到PayToken鋪路，Django來了。
昨天遇到的找不到情境被觸發ReturnURL，由於測試環境Message中解開的兩個網址：WebAtmURL以及OtpUrl連過去一個會出現錯誤訊息，一個連結不到。
📄️ Day13 - 將Django程式，放上Heroku！
昨天撰寫了一版最基礎的Django網站測試後，接著我們要來嘗試將網站佈署到雲端平台，讓API有機會能夠將PayToken傳入(這是我們的目的)。
📄️ Day14 - 使用Heroku Postgres資料庫，存儲訂單交易資訊
昨天成功將Django網站佈署到Heroku上，當然我們會需要撰寫BackendURL頁面來讓API可以被呼叫，但在此之前，有一項技能必須要先點亮才行，就是如何使用Heroku的資料庫！不然我們被API呼叫丟進來的PayToken，沒辦法儲存下來。
📄️ Day15 - 撰寫Django的Model，使用ORM和Heroku Postgres綁一起。
今天面臨了斷更的危機！
📄️ Day16 - 取得PayToken的最後一哩路很慢長
昨天抱病撰文，終於在本機端將單筆資料透過ORM的方法，成功將新增的訂單資料更新到Heroku Postgres資料庫中(非常感動)，今天我們要來完成剩下取得PayToken的最後一哩路。
📄️ Day17 - 永豐API虛擬帳戶付款與PayToken查詢與更新狀態
在經過了多日有一天沒一天的研究、寫Code與寫作，今天假日花了一點時間將原本從Jupyter Notebook零零散散的Code，搬到PyCharm後也是細細碎碎的程式碼重新進行重構與翻修，能寫成物件導向的方式就調整，終於將完整的ATM虛擬帳戶的實作完成了，有了這個基礎，剩下的信用卡付款就很簡單了。
📄️ Day18 - 提供信用卡付款以及取得PayToken流程
在我們花了不少時間終於完整的完成ATM付款並成功架設Heroku網站後取回PayToken，更新付款資訊。有了這些基礎後，我們在實作信用卡的部份基本上都可以用走到飛的狀態來進行。
📄️ Day19 - 防止掉單小幫手，以時間條件查詢交易訂單
細數一下之前實作的API功能，有建立訂單以及選擇支付方式(ATM虛擬帳號、信用卡付款)，拿到 永豐API透過ReturnURL或BackendURL回傳給我們的PayToken去問回付款狀態，現在即將進入最後一個永豐API的功能：訂單交易查詢
📄️ Day20 - 以Django Web框架實作永豐API線上支付模擬情境1
我們的豐收款主題完結了嗎？
📄️ Day21 - 以Django Web框架實作永豐API線上支付模擬情境2 - 購物車與付款方式確認頁
我們今天簡單帶一點Django Template繼承的概念，也就是當你有每一頁面具備無論在哪一樣都有相同的內容片段時，可採用這個方式把相同的部份拆出來，而具體不同的功能頁面只要先繼承後，再實作有差異的程式段，和程式碼把共用的地方設計成父類別，子類別先繼承後 再進行override是一樣的概念。
📄️ Day22 - 以Django Web框架實作永豐API線上支付模擬情境3 - 兩種付款方式實作
昨天使用了Bootstrap5、Vue，打造了我們的付款流程入口頁面後，今天要將之前的ATM虛擬帳戶轉帳付款以及信用卡線上刷卡的頁面也實作一下。
📄️ Day23 - 以Django Web框架實作永豐API線上支付模擬情境4 - 信用卡刷卡結果
昨天寫完兩種付款方式，有提到原先信用卡刷卡後的結果導回頁ReturnURL我們還沒實作，今天就把這一頁完成。
📄️ Day24 - 以Django Web框架實作永豐API線上支付模擬情境5 - 我的訂單
今天這篇是我們實作庫米狗屋●KummyShop的情境電商模擬的最終章了！今天我們要把先前建的一堆訂單可以在我的訂單頁面呈現出來。
📄️ Day25 - 永豐線上收款支付API功能實作總結1
今天開始要把我們先前花了24天研究與實作的永豐線上收付款API -- 豐收款 (funBIZ)，作一些總結與回顧，讓有興趣要使用的朋友，了解要注意的地方，以及還有哪些不在本次實作範圍內，但可以額外添加的部份。
📄️ Day26 - 永豐線上收款支付API功能實作總結2
在前半段的系列文章，我們把視野縮的很小，一篇一篇著重在每日趕進度的技術細節，看看怎麼使用Python來實作出規格書中的每一個功能，驗證每一個步驟的正確性。
📄️ Day27 - 永豐線上收款支付API功能實作總結3 - 如何讓機敏性設定值更有保護力
在前一篇文章，我們分析了各個資安防護的強弱要點，但由於固定式的初始四Hash組代碼是目前安全性最弱的部份，全仰賴人為保護，若是直接寫在Code裡面，那一來是作程式碼管控時會把具機敏性資料也一起撒出去給其他共同參與開發者外，另一方也降低建置佈署若未來有需要修改時的彈性(也就是若這些值要修改，就要重新改code，重新上線)。
📄️ Day28 - Shioaji - 超入門！永豐證券程式交易API快速上手 1
一晃眼，鐵人賽就進入了尾聲，先前一直說有時間要來寫Shioaji的，總是不能食言。我想就用最後兩篇的篇幅快速的導讀一下Shioaji的基礎入門功能。我發現自己之前每篇單日文章都希望寫的豐富一點，因此每天下班後幾乎都把時間貢獻在鐵人寫測試、研究與撰文上面，真的是有一點吃不消。而現在希望自己兩個主題都有參與到，貪心的結果就是每天弄的壓力很大，搞的下班比上班時還累。不過終究還是咬牙撐過來了。
📄️ Day29 - Shioaji - 超入門！永豐證券程式交易API快速上手 2
今天來看一下如何使用Shioaji問回歷史交易資料，不過在此先提醒一下，上一篇有講到的永豐講師的Youtube課程，其中講師特別提醒大家，這個用法僅僅是方便永豐API用戶測試用途使用，因為資源有限，並不建議大家過度使用這個方式進行歷史資料的大量撈取，若在非正常情況下的使用，永豐是有權將使用者的帳號鎖定。所以大家要使用的前提下，若僅進行資料測試時，盡量設定資料存取範圍，以及愛惜資源。
📄️ Day30 - 鐵人賽永豐APIs實戰30天，跪著都要完賽。
終於到了第30天了，對於第一次參加iThome鐵人賽的我而言覺得有點不真實呀，可以發表這篇文章有和想當年在寫論文時(嗯，很久很久以前)，最後寫誌謝文的感覺竟然是差不多的。(感動)