/images/avatar.jpg

J.N. Yiunn

FreeCodeCamp 挑戰:APIs and Microservices #20 - Get Query Parameter Input from the Client

FreeCodeCamp 題目連結 解說 這題要介紹 query parameter 和如何使用它。 Query Parameter 另一個從 client 拿到參數的方法是透過 query parameter,也就是常常會在 URL 的後面出現的一坨東西,像是這樣: 1 https://github.com/search?o=desc&q=querystring&s=stars 其中 path 是 /search,後面那一整串就是 query string。query string 從一個 ? 開始,後面是一組一組的 key=value,每一組再用 & 隔開。聽起來有點複雜,不過如果寫成這樣應該就很清楚了: 1 https://<domain>/<path>?<key1>=<value1>&<key2>=<value2>&<key3>=<value3> 而我們可以使用 req.query 這個 object 來得到 query parameters,如果以上面 GitHub 的那個例子舉例的話,req.query 就會是: 1 2 3 4 5 { o: 'desc', q: 'querystring', s: 'stars' } 和 route parameter一樣,這邊得到的都是 String,如果要當成整數來用的話,必須要搭配 parseInt() 來使用!

用 SCP 好麻煩?用 Croc 傳檔案,只需要一行指令!(不用再經過雲端硬碟了)

如何快速地把檔案傳到另外一台電腦? 隨身碟 這大概是最直覺的作法了,不過你必須先找得到你的隨身碟。 如果你很順利地找到你的隨身碟,接下來還要把隨身碟插到電腦 -> 把檔案複製出來 -> 卸載隨身碟 -> 再把隨身碟插到另一台電腦 -> 終於拿到檔案,而且這還不考慮 USB 平均要插 3 次才會成功。 所以除非是要傳非常大的檔案,否則我覺得還是太麻煩了。而且手邊不見得會有 USB 3.0 以上的隨身碟和孔可以用,如果退回到 USB 2.0 的速度的話只有 480Mbps 以下(通常是有 200Mbps 就偷笑了)。 AirDrop 不得不說 AirDrop 的非常好用的,不過限制也很明顯,那就是傳送和接收端兩邊必須都要是 Apple 的裝置才可以。 雖然也有像是 ShareDrop 這種類似 AirDrop 的服務,不過這類的服務大多是建立在區域網路或是 Wifi 直連上,也就是說,這類方式的另一個限制,就是傳送和接收端兩邊必須要在同一個地方或是在同一個網域內才行。 雲端硬碟 / 通訊軟體 / Email 這幾個服務我覺得比較類似就擺在一起討論了 基本上這些方式都需要登入,甚至要下載特定的軟體,有些也有檔案大小的上限,而且他們本來就不是被設計來傳輸檔案的,所以用起來都會有些彆扭的地方。另外這類服務大多數都會把檔案留在他們的伺服器上,如果你是要傳一些比較敏感的資料(比如說證件、文件翻拍),你有辦法安心的使用嗎? Send Anywhere 其實 Send Anywhere 已經算是蠻好用的服務了,你只要選擇好你要傳的檔案後,你就會得到一串數字(登入才能使用連結),然後在另一台電腦上一樣到 Send Anywhere 上輸入剛剛得到的那串數字之後,你就能在另外一台電腦接收到檔案。 不過 Send Anywhere 還是有缺點,就是還是必須要打開瀏覽器才能使用,有些進階功能還需要登入甚至收費。另外其實 Firefox 也曾經提供類似的服務,不過後來爲了防止被用來傳送有害的內容就結束服務了。或許 Send Anywhere 有一天也有可能步上 Firefox Send 的後塵,那麼到時候我們就必須再尋找下一個替代方案了。 SCP / FTP 假如你傳送或接收端的其中一邊是只能使用文字界面的伺服器的話,那你的選擇大概就只有這兩個了。

FreeCodeCamp 挑戰:APIs and Microservices #19 - Get Route Parameter Input from the Client

FreeCodeCamp 題目連結 解說 這題要介紹 route parameter 和如何使用它。 從 URL 得到資訊 有時候我們會需要根據 request path 內的參數而作出不同的回應。舉例來說,使用者想要得到 user1407 的資訊而發了一個 GET request 到 /user/1407,而我們需要拿到 1407 這個參數再去資料庫裡面撈到相對應的資料,才能回傳給使用者。 直接寫 app.get('/user/1407') 其實就能滿足這個需求。但資料庫裡面有那麼多 user,總不能幫每一個 user 都寫一個 route 吧? 這就是 route parameter 登場的時候了,我們可以把 path 的一部分當成一個參數來存取它,就不用爲每一個 user 都寫一個 route 了。 Express 的 route parameter 用上面的這個例子的話,在 Express 裡,我們可以把一個 route 的 path 寫成這樣: 1 2 3 app.get('/user/:userId', (req, res) => { // do whatever }) 而有使用者發出 request 到 /user/1407 時,我們就能在 route handler 裡用從 req.

FreeCodeCamp 挑戰:APIs and Microservices #18 - Chain Middleware to Create a Time Server

FreeCodeCamp 題目連結 解說 這題要介紹 middleware 的另外一個用法:chaining。 除了上一篇提到的 app.use() 以外,其實也可以把 middleware 串在 route 中間: 1 app.get("/mware", mware, (req, res) => res.send()) 也可以串超過一個的 middlewares: 1 app.get("/mware", mware1, mware2 , (req, res) => res.send()) 有沒有覺得有一點眼熟?我們拿出上一篇提到的幾種方法看一下: 1 2 3 4 app.use(mware) // 所有 request 都會經過(root-level middleware) app.use("/to-middleware", mware) // 只有 path 是 "/to-middleware" 開頭的 request 才會經過 app.post(mware) // 只有 method 是 "POST" 的 request 才會經過,當然 `get`、`patch`、`delete` 等等 method 也可以對應使用! app.

FreeCodeCamp 挑戰:APIs and Microservices #17 - Implement a Root-Level Request Logger Middleware

FreeCodeCamp 題目連結 解說 在這題我們要更深入瞭解 middleware 的運作機制。 我們可以這樣宣告一個 middleware: 1 2 3 4 5 6 function(req, res, next) { // do something here next() } 其中的 3 個參數: req: request,包含 request 的資訊 res: response,用於建立一個 response,以及回傳給 client next: 一個 callback function,用來代表下一個 middleware 你可能會問說要怎麽知道這是一個 middleware,不過很遺憾地,它就是一個普通的 function。 對,它就是一個普通的 function,不過我們還是可以從最後的 next() 看出一些端倪。我們看一下 middleware 的運作方式: 1 2 3 4 5 6 7 8 9 10 11 12 13 // 收到一個 request,req = {method: "GET", path: "/", .