第十屆鐵人賽 flask-restful DAY13-搞懂restful

甚麼是restful

說到restful就不能不提邦友kerkerj的從無到有打造 RESTful API service 系列其中[API] (1) – 定義 1 – 什麼是 REST/RESTful ?就載明了什麼是restful,想深入了解的可以讀一讀這篇文章,除此之外維基百科也載明了許多內容,在這裡筆者就重點式的提及一些觀念。

表現層狀態轉換(rest / restful)

相信讀者看到上面的解釋應該不知道他在說甚麼,其實rest也不是甚麼規範或是規定,他只是一種設計提供全球資訊網絡服務的軟體構建風格,而符合此風格的網路服務就稱為rest或是restful。
不過說了那麼多,到底是甚麼風格呢?基本上就是符合以下六種規範的風格即是:

  • 客戶-伺服器(Client-Server) – 由客戶端發起的需求
  • 無狀態(Stateless) – 通訊的狀態由客戶端負責維護
  • 快取(Cache) – 回應內容可以在通訊鏈的某處被快取,以改善網路效率。
  • 統一埠(Uniform Interface)- 此處透過超文本傳輸協定(HTTP)來傳遞資訊
  • 分層系統(Layered System)- 通過限制元件的行為,將架構分解為若干等級的層。

超文本傳輸協定(HTTP)

在rest規範中的統一埠規範即是以超文本傳輸協定來實現這規範,而甚麼是超文本傳輸協定呢,基本上目前你我使用的瀏覽器就是遵循這個規範來傳輸資訊的,而restful又怎麼跟這扯上邊呢,簡單講就是restful將超文本傳輸協定發揚光大,當客戶端發出需求不用特別思考就透過請求發法的規範來發出,而伺服器端就依據狀態碼的規範來回復狀態碼,如此客戶端與伺服器端雖然沒有共通的語言,但是彼此都知道相互說的東西是甚麼。接下來要分別針對請求方法以及狀態碼來說明一下,畢竟客戶端與伺服器端都知道但是讀者不知道這怎麼可以呢。

請求方法

這部分說明的是客戶端提出需求有下列幾種方法,每種方法都有特別的含意,以下針對每一種方法說明其內容

GET

向伺服器提出取得資訊的請求,所以伺服器處理此類的請求不應有更改資料的動作。

POST

向指定資源提交資料,請求伺服器進行處理更新資料的方法,若是存在資料時則會再新增一筆

PUT

向指定資源位置上傳其最新內容,如果存在就有資料就更新資料

PATCH

向伺服器提出修改局部資料的請求,與POST相比就是會新增很多筆資料

DELETE

向伺服器提出刪除資料的請求

狀態碼

這部分說明的是伺服器端回復客戶端的結果,雖然只是一個狀態碼但是卻能透過一個序號知道結果怎麼樣,以下就針對幾大類加以說明:

1xx

1開頭的代表訊息,客戶端的請求已經被伺服器給接收或是繼續處理中

2xx

2開頭的代表成功,客戶端的請求已經成功被伺服器接收以及理解並且接受

3xx

3開頭的代表重新導向,客戶端的請求雖然被伺服器給接受但是需要後續操作才能完成這一請求

4xx

4開頭的代表請求錯誤,客戶端的請求含有詞法錯誤或者無法被執行

5xx

5開頭的代表伺服器錯誤,伺服器在處理某個客戶端的正確請求時發生錯誤

風格/規範

因為restful僅是一種風格,所以說再撰寫restfulapi沒有完全遵照上述規範來處理會怎樣呢?基本上…當然不會怎樣,但是就是你說話跟別人說的話不同如此而已,所以頂多造成雞同鴨講的局面,所以為了避免這種局面發上,還是照著這種規範來處理吧,避免日後抱怨為什麼都沒有人懂你。

小結

沒想到說明重點比寫代碼還困難,希望沒有誤人子弟的內容,若是有請回復告知以便修改,說明完規範後就要準備開始說明如何撰寫restfulapi,不過restfulapi是一個接受客戶端需求處理並回覆的伺服器操作,沒有時做客戶端要怎麼確認所寫的內容是正確的呢?所以下一部分先教授撰寫api的利器postman的使用方式,敬請期待。

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *