說到restful就不能不提邦友kerkerj的從無到有打造 RESTful API service 系列其中[API] (1) - 定義 1 - 什麼是 REST/RESTful ?就載明了什麼是restful,想深入了解的可以讀一讀這篇文章,除此之外維基百科也載明了許多內容,在這裡筆者就重點式的提及一些觀念。
本文章同步放置於此
相信讀者看到上面的解釋應該不知道他在說甚麼,其實rest也不是甚麼規範或是規定,他只是一種設計提供全球資訊網絡服務的軟體構建風格,而符合此風格的網路服務就稱為rest或是restful。
不過說了那麼多,到底是甚麼風格呢?基本上就是符合以下六種規範的風格即是:
在rest規範中的統一埠規範即是以超文本傳輸協定來實現這規範,而甚麼是超文本傳輸協定呢,基本上目前你我使用的瀏覽器就是遵循這個規範來傳輸資訊的,而restful又怎麼跟這扯上邊呢,簡單講就是restful將超文本傳輸協定發揚光大,當客戶端發出需求不用特別思考就透過請求發法的規範來發出,而伺服器端就依據狀態碼的規範來回復狀態碼,如此客戶端與伺服器端雖然沒有共通的語言,但是彼此都知道相互說的東西是甚麼。接下來要分別針對請求方法以及狀態碼來說明一下,畢竟客戶端與伺服器端都知道但是讀者不知道這怎麼可以呢。
這部分說明的是客戶端提出需求有下列幾種方法,每種方法都有特別的含意,以下針對每一種方法說明其內容
向伺服器提出取得
資訊的請求,所以伺服器處理此類的請求不應有更改資料的動作。
向指定資源提交資料,請求伺服器進行處理更新資料的方法,若是存在資料時則會再新增
一筆
向指定資源位置上傳其最新內容,如果存在就有資料就更新
資料
向伺服器提出修改局部資料的請求,與POST
相比就是會新增很多筆
資料
向伺服器提出刪除
資料的請求
這部分說明的是伺服器端回復客戶端的結果,雖然只是一個狀態碼但是卻能透過一個序號知道結果怎麼樣,以下就針對幾大類加以說明:
1開頭的代表訊息
,客戶端的請求已經被伺服器給接收或是繼續處理中
2開頭的代表成功
,客戶端的請求已經成功被伺服器接收以及理解並且接受
3開頭的代表重新導向
,客戶端的請求雖然被伺服器給接受但是需要後續操作才能完成這一請求
4開頭的代表請求錯誤
,客戶端的請求含有詞法錯誤或者無法被執行
5開頭的代表伺服器錯誤
,伺服器在處理某個客戶端的正確請求時發生錯誤
因為restful僅是一種風格,所以說再撰寫restfulapi沒有完全遵照上述規範來處理會怎樣呢?基本上...當然不會怎樣,但是就是你說話跟別人說的話不同如此而已,所以頂多造成雞同鴨講的局面,所以為了避免這種局面發上,還是照著這種規範來處理吧,避免日後抱怨為什麼都沒有人懂你。
沒想到說明重點比寫代碼還困難,希望沒有誤人子弟的內容,若是有請回復告知以便修改,說明完規範後就要準備開始說明如何撰寫restfulapi,不過restfulapi是一個接受客戶端需求處理並回覆的伺服器操作,沒有時做客戶端要怎麼確認所寫的內容是正確的呢?所以下一部分先教授撰寫api的利器postman的使用方式,敬請期待。