前言

還記得在Day 4的文章裡，我們講了Request Driven的概念和優點，透過電商平台的範例讓大家更加了解Request Driven。

從Day 4到今天也過了快10天，大家可能忘了Request Driven的流程，讓我們在舉個例子快速回顧，讓各位前世的記憶復甦。

好了～我們開始吧！！

回顧Request Driven流程

假設有個資料管理平台：

今天user想點開資料夾查看裡面的內容，此時瀏覽器會發送一個帶有folder id的GET請求給伺服端，期望能拿到這筆資料夾的相關資訊。

那麼，瀏覽器如何跟伺服端進行互動？
Day 5的文章我們提到RESTFul API的設計協定，對於瀏覽器與伺服端，Request Driven採用RESTFul API進行互動。

RESTFul API:

[GET] /api/folders/{id}

伺服端收到來自瀏覽器發來的GET請求之後，會用folder id去db搜尋有此id的資料夾:

• 若db有找到這筆資料，會用JSON的格式將資料夾的相關資料回傳給瀏覽器
• 若db沒有找到，則會噴status code為404 Not found並且將錯誤訊息回傳回去

回顧Request Driven Architecture優點

透過簡單的get folder的範例，能了解到Request Driven有以下幾個優點：

1. 易於理解與實作
2. 即時回應
3. 能很好的進行錯誤處理

Request Driven限制探討

可惜的是，儘管Request Driven本身有許多的優點，如上面所列的那些，但同時也存在一些限制與挑戰。
隨著使用者需求以及系統複雜度的增加，Request Driven的問題就產生了，同樣舉個例子說明：

一樣是資料管理平台:

今天使用者想要在A資料夾底下建立B資料夾，此時瀏覽器會發送一個帶有payload的POST請求給伺服端，期望將B資料夾的資訊存到db當中。

Request Driven同樣採用RESTFul API的協定

RESTFul API:

[POST] /api/folders

request body:

{
    'parentId': 'xxx'
    'name': 'B'
}

伺服端收到來自瀏覽器發來的POST請求之後，要處理的事情開始複雜起來了:

• 檢查request的payload的格式
• 沒問題的話，接著打GET folder的service，確認資料夾A是否存在於db中
• 有在db的話，進一步去db搜尋在資料夾A底下是否有資料夾B
• 若沒有，才會在db中建立資料夾B的資料並回傳給瀏覽器

在這每一項當中，每一個步驟都跟前一個步驟有依賴關係，如果其中一項失敗了，那麼後續的操作就無法進行；對於有依賴關係的service或api，要對它進行測試以及維護的成本、複雜度就很高。

總結

終於回歸到Request Driven上，今天幫助大家回顧Request Driven的流程與優點，並開始說明它所帶來的限制。今天舉個例子簡單講而已，明天會為大家帶來更詳細的解釋，讓大家知道為什麼這些問題會讓開發人員掉頭髮((抓頭。

好了～～今天就到這邊！！