在探討何謂Restful Web API先來談談為何Web開發要分成前端的Web App跟後端的Api Server。
這是傳統的網頁流程
傳統的網頁流程有以下的缺點：
- Data 跟 Presentation Logic無法切割，開發會使程式碼過於複雜難以測試、除錯。
- Data 跟 Presentation Logic混和在一起，Presentation只要一變更，Data也要重新產生，反之Data一變更Presentation也要重新產生，Cache機制難以應用在Presentation中。
- 伺服器負責Data的產生並與Presentation Logic的整合，伺服器負擔太重。
所以為了將Data跟Presentation Logic徹底切開，Server一分為二成前端Web跟後端API，網頁流程就變成：
這樣的網頁流程有以下的優點：
- Data跟Presentation Logic分離後，Web Server可以透過快取機制將資料存在Web Server端，雖然這樣的架構表面上要發多一次request，但在資料沒有變更的情況下，只需要單純執行presentation logic就能將結果回傳給client，而presentation logic所消耗的資源相較於資料產生而言是少了許多，降低server負擔。
- 另外client端也有他的快取機制，只要前端的設計沒有更改過，presentation logic不變的情況下，client端也沒必要發重發request給Web Server，Presentation不用重傳，節省不少網路流量。
- Data Logic 跟 Presentation Logic分離後，在開發方面也能穩定許多，前後端邏輯職責劃分清楚不互相影響，並且在後期開發上，Api Server也還能重複給不同的平台使用，提高系統的擴張性。
了解了Api 在 Web 開發中的必要性後，就可以談論在開發Api時最常用的設計風格，Restful，全名為Representational State Transfer，表徵狀態的切換。
所謂的「表徵」就是指前端的檔案，例如HTML檔、圖片檔、XML文件等，其中HTML檔為最常見的「表徵」，而「狀態的切換」代表著使用者如何跟這些表徵互動，例如讀取某一個頁面(表徵)的資料，透過表單進行新增、修改、刪除某頁面(表徵)的資料，而當表徵狀態發生切換時，前端Web Server就需要與後端Api Server進行互動。
所以Restful Api這種設計風格，就是讓Web Server發生表徵狀態切換時，能更方便的向Api索取資料。
Restful Api是由三種元件組成的，Nouns、Verb和Content-Types。
Nouns：
用來定義Api的接口的URL，每一個Nouns代表著一個Data，例如電商平台可能會有product的Data，那麼api接口的URL就會變成 https://api_server_name/api_version/products。
對應到前端Web的話，每一個表徵可能會有一個到多個Data 組成，也就是說當一個表徵產生或者狀態改變時，可能會向Api Server發送一個到多個的request去要求資料。
Verb：
用來描述對Nouns(Data)的操作動作，在Web Api中實作的通訊協定是用HTTP，所以對Data的操作動作就是用HTTP的Method，例如Get、Post、Put、Patch、Delete。
對應到前端Web的話，當使用者與表徵互動產生表徵狀態改變時，Web Server就必須使用HTTP Method來代表使用者與表徵互動的行為，例如展示某個表徵內的資料就要用Get，新增資料到表徵時就要用Post，修改用Put或Patch，刪除則用Delete。
Content-Types：
Api用來呈現Data的方式或者稱格式，常見的格式有JSON、XML、YAML等等，比較常用的是JSON，由於他很輕量，所以很適合HTTP的傳輸。
對應到前端Web的話，通常Web Server接受的HTTP Response後會透過HTTP Header中的content-type去查看response的資料格式，並呼叫對應的function去解析資料內容，這個動作稱作序列化(Serialization)，將一般的檔案格式轉化成，程式語言可以使用的資料結構，例如Array或Hash。
最後來談談Restful Api的優缺點吧~
優點：
簡單且統一的Api接口，由於在操作Data時都必須透過HTTP所規範的Method，另外接口中的URL只會有單純的代表Data的Nouns，不會有像是 https://api_name/api_versiom/data/get_all 這種url，讓不同的前端Server能夠更方便的與後端Api對接，並且每一種url接口就代表一種data，降低了系統資料之間的耦合性，讓後端api開發上好維護且彈性許多。
缺點：
但低耦合就代表著高鬆散，當前端Web的Presentation Logic過於複雜時，例如一個頁面(表徵)需要多種資料時，就必須多發幾個request向後端要資料，例如一個部落格頁面除了要文章內容還要作者資料時，就必須一次發兩個request，一旦Presentation Logic複雜起來，就會大大影響系統的效能。
但最近由FB所開發的GraphQL就能解決Restful Api資料結構過於鬆散的問題，但實際實作上會遇到什麼問題小弟我就還不太了解了。
Restful的淺談就到這邊，再次強調Restful只是一個設計風格，並不是一個類似於framework的概念，可以想像是一個寫詩的風格，而他的風格著重簡單統一，但除了上述的三大元件外，還有許多細節需要注意，我就放在下一篇文章中吧！
References：
