上一回我們成功把點選的公車路線的到站情況資訊 api 給接了回來

但現在我們面臨了新的挑戰！

公車到站時間有來回程的區別！

那麼如何從 api 獲取時就區分出來回程呢
好在這個公共交通資訊平台的 api 真的非常強大
對，它可以幫我們做到
使用 api 本身提供的 filter ，再篩選出路線號的時候一併區分成去程跟回程兩支 api 網址

但是！
人生最討厭就是這個"霸特"

我們都知道這些 api 資料是使用 AJAX 取得的
但這些資料在被撈回來之後就是靜態的了
儘管它本身所處的 database 資料有動態更動，若我們不重新抓取一次資料，本地端撈回來的資料就不會改變

=> 於是，我們知道必須幫「拉回來的網址」寫一個排程！才能定時去重複接收資料，渲染畫面上的預估到站時間才會改變！

「我們都有個很美好的預期」

「但往往事實是...」

「幹幹幹幹為什麼我的 setInterval 爆炸啦」
「為什麼我的去程回程路線一直沒辦法正確渲染 QQ」
「靠杯我把 api 給 call 爆了 (眼神死」

── 以上為開發時的真實經歷 ──
　
　
好了，我們來講講今天題目的主角吧..
　

status of 429 (too manay request)

一開始在寫的時候，只想說為什麼資料畫面都出不來了
打開 console 一看
「靠杯這什麼鬼」

嗚嗚我還特別去爬了一下 status of 429 到底是什麼情況，網路上的討論非常的少..
連保哥的 網頁開發人員應了解的 HTTP 狀態碼 當中都沒有特別提到

結果最後終於在 Stackflow 上面找到這樣一篇
the server responded with a status of 429 (Too Many Requests) intlTelInput.js

── 大意大致是說，免費的 api 一日大約都能做 1000次呼叫請求，但當你使用同個 ip 連續呼叫同支 api 超過1000次以上，就會被斷開存取(/使用)權限

白話文，「你今天 Call api 的次數太狂了，我們暫時不讓你用了 (踹」

系統提示：「第一次寫 AJAX 就把 Open Data Call爆 (status of 429)」 成就解鎖

　
　
至於具體到底是怎麼把　api 給 Call 爆的..，我們下回揭曉！(繼續富堅

>>隊友任意門<<

• Jason 勇者Jason和前端之鑰
• Clover 用Vue與firebase開發訂便當系統實錄
• aflect 我的UI/UX奮鬥屎
• GG 一隻巨大的UI/UX菜鳥
• Jimmy ES666
• R-yin 菜鳥前端奮鬥史(欸?

我是小菜鳥阿陰，我們下次見！