百日轉職前端工程師：第四週秒懂網路基礎《DAY 8》

大家好，這是百日轉職前端工程師的 Day8，也是 7/16（四）。今天開始要來復盤之前學過練習過網路基礎，從這篇開始會在寫作形式上做一些改變，因為我發現之前寫作上為了文章的完整性讓我在每次動筆前有太大的壓力，也因為沒有較長的時間寫作導致我寫作的頻次降低，因此之後這個系列將會降低完整性，但求更常記錄下更多學習上細節。

復盤系列將會回答每一週學習上的自我檢測目標。

一、網路背後大概的運作模式

網路背後的運作模式可以理解為兩個人互相在傳紙條「溝通」

但當傳紙條的頻次增加但其中有很多傳紙條的目的重複時，就可以透過標準化建立一些溝通規則，這些規則在網路中正式的名稱為「協定（Protocol）」，透過這些規則來簡化傳送的效率，減少重複的工，這也是網路的雛形。

傳紙條溝通時會有一些最基本的資訊，可以用其來理解網路背後的模式

1. 寄件人
2. 收件人
3. 收件人地址
4. 信件主旨
5. 信件內容

二、什麼是 Request 跟 Response

• 簡單來說當你 (Clients) 傳紙條送出一張紙條，這個動作通常就叫做 Request。
• 而你這張紙條通常是送到的收件者，在網路上會是某台存放資料的電腦，又叫作伺服器 ( Server)
• 而如果你的紙條有一些要求，收件者拿到你的要求後，就會根據你的要求傳送回紙條給你，紙條裡面有根據你的要求附上的資料，這個動作叫做 Response

三、什麼是 DNS 以及運作原理

• 通常當你在傳送紙條的時候，你必須要寫上地址，在網路上最精確的地址叫做 IP
• 現行的有四碼 (xxx.xxx.xxx.xxx) 和六碼，四碼的 IP 快被用完了所以有六碼
• 而我們所謂的網址其實是對應到一組 IP 位置。

網址 (ex: www.google.com) 有點像是地址的簡稱方便大家記憶

當郵差收到你的紙條要幫忙你算送時，他們會去問熟門熟路的老司機，老司機一看就知道精確的地址在哪 (ex: 192.168.50.1)，這位老司機在網路上就叫做 網域名稱系統 (DNS)，只要 Clients 丟網址給他們就會回傳給網址的 IP。

四、HTTP 與 HTTPS 的差異

前面提到的協定 (Protocol) 分類成四層的 TCP/IP 中各有不同的協定

1. 應用層
2. 傳輸層
3. 網路層
4. 連結層

HTTP (HyperText Transfer Protocol) 全名為超文本傳輸協，是應用層中的協定

• HTTP 也是我們最常見到網址前面加的那個神秘的東東，就是屬於應用層的一個最廣泛常見的協定幫助各大網址跟伺服器溝通
• HTTPS 中的 S 全名為 Security，HTTPS 功能與 HTTP 相似但是又加上一些加密相關的功能，讓資料在網路上溝通的時候能夠更加安全

五、localhost 跟 127.0.0.1 是什麼

localhost 是一個在電腦網路中用於表示「此電腦」的主機名的保留網域名稱

• 其對應到的 IP 為 127.0.0.1，每台電腦的主機 IP 都是 127.0.0.1
• 其可以理解為你自家的秘密入口，只有你自己能夠透過這個入口去查看你的主機的狀況
• 但其他人要透過網路去跟你的主機做溝通的話，還是需要你的網路位置 (IP)

六、GET 與 POST 的差別

GET 和 POST 都是在表達你傳紙條的要做什麼事，也就是你發的 Request 背後的「動作」為何？

• GET 是要拿取資料
• POST 是為了創建資料

基本上其沒有實質性的差異，用的都是同一個傳輸層協定，硬要都用 POST 也可以達到跟 GET 同樣的效果

七、常用的 HTTP Header

可以想像為在傳紙條的比喻中

• 紙條放額外資訊的位置是放在 HTTP header (會放的資料類型和資訊可參考常用的 HTTP Header)
• 而主要的資訊會放在 HTTP Body

八、什麼是 API

API 是取用資料（可能從資料庫、程式，或檔案.......等）的一套「溝通介面」

• API 需要有 API 網址和 API 規範
• 通常前端工程師通過 API 去取用資料庫中的資料，同時也必須遵守 API 自有的一套規範

這套規範通常是由撰寫 API 的後端工程師所規範

• 之所以要有 API 是為了讓取用資料庫資料的流程可以透過標準化所簡化
• 也是為了讓外部人士要取用資料庫資料的時候，能夠保障資料庫中原始資料的資訊安全。

通常對外開放的 API 都會有一套 API 文件，EX: Twitter API 文件

九、使用 node.js 寫出串接 API 的程式

可以透過一些 library 類似 Request - Simplified HTTP client ，去直接使用內建的函式撰寫程式碼去跟 API 做溝通，取用或者傳遞資料。

十、HTTP method 有哪些

為了溝通上的統一性讓大家可以在一致的格式下快速理解程式碼，定義了所謂的 RESTFUL API

• 全名 Representational State Transfer (表現層狀態轉移)
• 是一種設計風格將 API 網址盡可能的在格式上一致且簡潔
• 而將要執行的「動作」放在了「請求方法 (Request Method)」 上表明這是何種類型的 Request/ Response

動作 （大致上）又分為

• GET: 用於拿取資源
• POST: 用於新增資源
• DELETE: 刪除資源
• PATCT: 用於部分更新資源
• OPTION: 查看這個伺服器支援哪些方法
• HEAD: 只拿取頭部資源

十一、基本的 HTTP status code

基本上 status code 就是在伺服器回應 (Response) 你的請求時，會附帶的訊息，告訴你收到你的請求後回覆予你現在的狀態。

基本上可以分成以下幾類

• 1xx: 表示請求已被接受，需要繼續處理，很少見到
  • 100: Server 成功接收、但 Client 還要進行一些處理
• 2xx: 表示請求成功
  • 200: 表示伺服器成功處理了請求
  • 204: 表示成功但是沒有回傳任何東西
• 3xx: 表示需要重新導向
  • 301: 東西永久被移動到了新位置
  • 302: 東西暫時被移動到了新位置，下次丟 Request 還是會重新造訪一次原位置
  • 303: 通知 Clients 去另一個網址查看上傳表單後的結果
  • 304: 東西跟之前長一樣，可以從快取拿就好
• 4xx: 表示用戶端有錯誤
  • 400: 請求語法錯誤、或資源太大…等等
  • 401: 未認證，可能需要登入或 Token
  • 403: 沒有權限
  • 404: 你要的東西，伺服器找不到
• 5xx: 表示伺服器有錯誤
  • 500: 通用的錯誤訊息
  • 501: Not Implemented
  • 503: 由於維護或者過載，伺服器暫時無法處理請求。（搶票時）
  • 504: 不知為何伺服器上沒有回應，超過正常的時間

十二、總結

在看 API 文件上還滿卡的，一開始同時不熟悉 Request 和 API 的情況下有點像是瞎子摸象，之後卡關時可能要注意要去花些時間先弄懂手上的工具到底怎麼用，除此之外之後有機會看 API 文件時也要特別注意整理出一些快速抓重點的架構，而在 Request 的格式上也需要再花些時間熟悉，不過瞭解怎麼串 API 以後其實就能夠寫出一些簡易的爬蟲程式了，還滿有趣的。