前言

昨天提到了 HTTP 的封包結構，不過在更深入 HTTP 協定之前，我想先來介紹一下大家或多或少有聽過的REST~

REST 是什麼？

REST（表現層狀態轉換）是 Roy Thomas Fielding 在其 2000 年的論文中定義的一種軟體架構風格，目的在於在為快速增長的 Web 提供一個架構模型。Web 涉及不同作業系統和多樣化檔案格式，REST 透過統一的介面，減少端對端溝通的耗時，更有效解析傳遞的數據，並且提高了可擴充性，以應對 Web 使用需求的快速增長，同時也透過 URL path 與 Http method 這種簡潔明瞭的表達方式讓開發者間交流更加順暢。

REST 架構是一種混合風格，源自於其他網路的基礎架構風格，並且結合了 REST 所定義的constraints，當符合這些條件時，這個系統就可以稱之為 Restful（形容詞）

為什麼 REST 定義這些 constraints？

1. Client-Server：將使用者端介面與伺服器端的資料處理分開處理，降低兩者之間的耦合度，不同設備上的客戶端（如手機、電腦）能與同一伺服器進行溝通，增加系統的兼容性。同時也使得雙方能夠獨自擴展、更新，不會互相影響運作。

2. Stateless：無狀態性，每次的請求都是獨立的，代表每次發出的請求都要能夠使伺服器端完整理解，不需要依賴其他的請求，提高了可靠性。而由於 session state（會話狀態）都是由使用者端處理，並與請求一同發出，因此不一定同一個使用者的請求都需要單一伺服器進行處理，可以將請求轉發到其他伺服器進行處理，使得伺服器端的可擴展性進一步的提高。不過缺點則是一系列的請求會需要重複傳送資料，造成效能的消耗。

3. Cache：支援使用者端與伺服器端的快取，將一些頁面共用的影像或是資料進行快取，以減低伺服器的負擔並降低請求造成的延遲時間。

4. Uniform Interface：統一的介面，是 REST 與其他網路架構風格最大的差別所在，透過標準化以及統一的抽象介面，使得所有資源的訪問方式保持一致，簡化了數據傳送間的複雜性，並由以下四種 Interface constraints 所定義：

   • identification of resources：所有事物都被視為資源（ex. web文件）。每個資源都有一個唯一的 URI（統一資源標識符）來標識。
     例如：https://ithelp.ithome.com.tw/articles/1111111，指向了一個特定的文章，這樣的表示方式識別性較高且容易理解。
   • manipulation of resources through representations：透過特定的方法對資源進行操作。
     例如：GET https://ithelp.ithome.com.tw/articles/1111111 ，代表著這個操作是要取得這個網址的內容。
   • self-descriptive messages：自我描述資訊，代表 messages 本身應該包含足夠的資訊，使得接收方能夠理解如何處理該數據。
   • hypermedia as the engine of application state：這個部分我沒有到很理解，不過查了一下stackoverflow的討論，這個部分強調使用者端應該根據伺服器提供的超鏈接來導航和操作資源，而不是事先知道所有可能的 URI（統一資源標識符），使得使用者可以根據伺服器的 response 靈活的操作資源，並且伺服器進行更新連結時對於使用者端也不會造成影響，只要更改 response的內容即可。
     例如：使用者發出請求GET https://ithelp.ithome.com.tw/articles/1111111 ，此時伺服器回應的 JSON 可能如下

   {link:
     {
       "rel": "comments",
       "href": "/articles/1111111/comments"
     }
   }
   

   代表使用者想要查看這篇文章的評論時，就可以根據 response發出
   GET https://api.ithelp.ithome.com.tw/articles/1111111/comments這個請求。

5. Layered System：REST 由多個層次組成，提高了層次間的獨立性，使每一層次的職責能夠分離。這樣的設計讓開發者能專注於特定的功能，並簡化系統的維護。這種層次結構允許將中介層（如代理伺服器和負載均衡器）插入系統中，進一步增強系統的靈活性和可擴展性，同時減少客戶端的複雜性。分層系統也有助於增強整體安全性，透過將安全控制和檢查邏輯置於中介層，系統可以有效地隱藏伺服器的內部實現細節，降低直接訪問伺服器的風險。

6. Code on demand：非強制的 constraints，伺服器可以在請求時將可執行的代碼傳送到使用者端（例如： JavaScript）並擴展使用者端的功能。

小結

今天介紹了一下我所理解的 REST 是什麼，以及 REST 所定義出的一些條件，如果看完這篇文章還是一頭霧水的話，可以參考下列的網站，或許可以更清楚的了解，明天會繼續介紹關於 HTTP 協定的內容，gogo！

參考資料

How I explained REST to my wife...
淺談 REST 軟體架構風格 (Part.I) - 從了解 REST 到設計 RESTful！
Architectural Styles and the Design of Network-based Software Architectures
what is hypermedia , hypermedia controls, hypermedia formats
Intro to REST (aka. What Is REST Anyway?)