淺談Restful Web API

徐銘佑
徐銘佑
Sep 6, 2018 · 7 min read

在探討何謂Restful Web API先來談談為何Web開發要分成前端的Web App跟後端的Api Server。

這是傳統的網頁流程

傳統的網頁流程有以下的缺點:

  1. Data 跟 Presentation Logic無法切割,開發會使程式碼過於複雜難以測試、除錯。
  2. Data 跟 Presentation Logic混和在一起,Presentation只要一變更,Data也要重新產生,反之Data一變更Presentation也要重新產生,Cache機制難以應用在Presentation中。
  3. 伺服器負責Data的產生並與Presentation Logic的整合,伺服器負擔太重。

所以為了將Data跟Presentation Logic徹底切開,Server一分為二成前端Web跟後端API,網頁流程就變成:

這樣的網頁流程有以下的優點:

  1. Data跟Presentation Logic分離後,Web Server可以透過快取機制將資料存在Web Server端,雖然這樣的架構表面上要發多一次request,但在資料沒有變更的情況下,只需要單純執行presentation logic就能將結果回傳給client,而presentation logic所消耗的資源相較於資料產生而言是少了許多,降低server負擔。
  2. 另外client端也有他的快取機制,只要前端的設計沒有更改過,presentation logic不變的情況下,client端也沒必要發重發request給Web Server,Presentation不用重傳,節省不少網路流量。
  3. 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:

https://blog.toright.com/posts/5523/restful-api-%E8%A8%AD%E8%A8%88%E6%BA%96%E5%89%87%E8%88%87%E5%AF%A6%E5%8B%99%E7%B6%93%E9%A9%97.html

https://blog.toright.com/posts/725/representational-state-transfer-%E8%BB%9F%E9%AB%94%E6%9E%B6%E6%A7%8B%E9%A2%A8%E6%A0%BC%E4%BB%8B%E7%B4%B9-part-i-%E5%BE%9E%E4%BA%86%E8%A7%A3-rest-%E5%88%B0%E8%A8%AD%E8%A8%88-restful%EF%BC%81.html

https://www.slideshare.net/AmigoChan/restful-api-design

    Written by

    徐銘佑

    初生之犢,很畏虎。希望大家對於我寫的東西能給予指點,並點出不正確的地方,讓小弟我能學到更多的東西。

    Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
    Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
    Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade