REST與RESTFul API最佳實踐

我常常會面試一些作PHP的開發者，讓我很奇怪的是，10我的總有8個多不知道什麼是REST服務，甚至是沒有據說過。但RESTFul API已是如今互聯網裏對外開放接口的主流模式，可參考：

豆瓣API https://developers.douban.com/wiki/?title=api_v2

GitHub https://developer.github.com/v3/

數一數年限，據我接觸REST到如今也差很少有8年左右了。可能你們如今對從JavaScript客戶端直接訪問服務器API這種模式很是的習覺得常，但在8年前，Web並非如今這個樣子的。要說REST，咱們先來看看在REST流行以前Web客戶端是如何訪問服務器接口的。

早期在移動端沒有流行以前，Web API的概念還很是的弱，當時是網站盛行的年代，基本遵循着後臺-前端的模型。後臺產生數據，而後經過「模板」的形式將數據綁定到前端HTML代碼裏（渲染）。以下圖所示：

那麼這裏就有一個「域」的概念，JavaScript只能訪問同一個域的服務器。好比咱們將一個站點部署在A這個域名www.a.com下，那麼這個站點的前端JavaScript只能訪問域名爲www.a.com的服務端。若是咱們須要訪問非A站點的其餘「服務」怎麼辦？看看下圖：

在當時通用的作法是使用SOAP，Simple Object Access Protocol，簡單對象協議，它使用XML做爲數據的描述。咱們看看使用SOAP的解決方案：

JavaScript是不能直接訪問SOAP服務的，須要首先訪問本身的網站後臺，再有網站後臺訪問SOAP服務。並且不一樣語言的網站後臺，方位SOAP服務都須要有首先生成本身特定語言的「代理類」，Java有Java的、C#有C#的，這至關的繁瑣與很差理解。這個時候咱們的思考點來了，網站的後臺對我來講意義是什麼？ 我爲何不能直接訪問服務？爲何我不能把網站裏的業務代碼也提取成服務，最後變成如下的理想狀況：

網站的後臺幾乎是個「殼子」，只負責網站自己的HTML頁面、CSS、JavaScript文件等靜態頁面。而業務邏輯，交給服務來提供就行了。這樣作的最大的好處是，業務變得獨立了，能夠被多個「網站」來共享訪問了。有沒有以爲挺熟悉？這個模式就是如今VUE、AngularJS等框架作的單頁面應用程序。可是，在當時這種模式並不流行。我在不少年前就嘗試這樣的思惟來構建Web，可是因爲沒有如今VUE、AngularJS等強大的SPA框架支持，效果並很差。但，我相信這種簡潔的模式是Web的將來。我一貫崇尚簡潔，當年丟掉Flex、Silverlight、ASP.Net WebForm，獨獨選擇JavaScript就是由於其餘幾個封裝太多。

不少人認爲模板引擎就是很好的先後端分離，可我不這麼認爲，SPA纔是真正的先後端分離，他們之間使用AJax通訊，前端就是最簡單的HTML，前端開發人員一行服務器代碼都看不到，這纔是真的和語言無關，纔是真正的先後端分離。

我來分析下，爲何之前SPA應用並不流行。
第一，一個是網站的思惟根深蒂固；
第二，就是出於性能考慮，單頁面頻繁的Ajax請求將給服務器形成巨大的壓力。而網站網頁的靜態化技術已是很是的成熟的了，因此SPA這個概念在早期並不怎麼提倡。並且SPA也有本身的侷限性，並非全部的網站都適合用SPA來代替。但如今服務器緩存技術的發展（特別是Memcache和Redis出現後）大大的解決了服務器支持SPA負載太高的問題，甚至比傳統的網頁靜態化技術更加的簡單易用；再加上VUE、AngularJS強大的能力，這才使SPA真正的流行起來。
第三，前端要跨域訪問服務器在當時並非那麼容易，沒有一個標準的規範來定義跨域，各類旁門左道的跨域都不是那麼的好用。

那麼我我的認爲有兩個標緻性的事物刷新了人們對於API和服務的理解：一個是移動端的流行，第二個就是REST理念的流行。
移動端咱們就不談了。咱們來談談REST。我我的認爲REST並非什麼技術，而是因爲它的流行，讓人們逐漸的接受了服務即資源，擴展和打破了開發者對Web的理解。

沒有REST的時候，客戶端可不能夠直接跨域訪問服務？能夠。但並無一個標準來引導開發者如何設計出適合服務的API接口。REST的流行，替代了SOAP（某些領域裏SOAP仍是有一席之地），它足夠簡單、輕量、語義明確，很是適合移動端盛行的這個年代。

REST：REpresentational State Transfer，中譯爲「表屬性狀態傳遞」。這是什麼鬼？這並不重要，原本就個名字就源自於國外的一個博士的一篇論文。咱們主要要知道基於這篇論文裏的理論，衍生出了RESTFul API的接口設計風格。
咱們一塊兒來看看RESTFul API有哪些特色：

1. 基於「資源」，數據也好、服務也好，在RESTFul設計裏一切都是資源。
2. 無狀態。一次調用通常就會返回結果，不存在相似於「打開鏈接-訪問數據-關閉鏈接」這種依賴於上一次調用的狀況。
3. URL中一般不出現動詞，只有名詞
4. URL語義清晰、明確
5. 使用HTTP的GET、POST、DELETE、PUT來表示對於資源的增刪改查

6. 使用JSON不使用XML

   我舉個例子：
   網站：/get_user?id=3
   RESTFul: GET /user/3 (GET是HTTP類型)

有些同窗可能會說，GET、POST我也常常用啊。可是在網站裏的GET和POST同RESTFul中的GET、POST是不同的。網站裏使用GET、POST的選擇點在於，簡單的用GET、複雜對象用POST；但在REST裏，GET對應的是查詢一個資源，而POST對應的是新增一個資源，意義是決然不一樣的。理解這一點很是重要。

好，咱們接着來看一看RESTFul API的一些最佳實踐原則：

1. 使用HTTP動詞表示增刪改查資源， GET：查詢，POST：新增，PUT：更新，DELETE：刪除
2. 返回結果必須使用JSON
3. HTTP狀態碼，在REST中都有特定的意義：200，201,202,204,400,401,403,500。好比401表示用戶身份認證失敗，403表示你驗證身份經過了，但這個資源你不能操做。
4. 若是出現錯誤，返回一個錯誤碼。好比我一般是這麼定義的：

1. API必須有版本的概念，v1，v2，v3
2. 使用Token令牌來作用戶身份的校驗與權限分級，而不是Cookie。
3. url中大小寫不敏感，不要出現大寫字母
4. 使用 - 而不是使用 _ 作URL路徑中字符串鏈接。
5. 有一份漂亮的文檔~（很重要）

以上只是列出了RESTFul的部分實踐原則，並不是所有。 給出一個典型的RESTFul API設計風格：

https://api.z.cn/v1/product/recent?page=3&size=20

以上URL很是容易理解，分頁獲取最新若干的Product資源。

最後，咱們想聊一下，RESTFul API到底好用嗎？某些狀況好用，某些狀況很是很差用。什麼狀況好用，什麼狀況很差用呢？
個人一個經驗性的總結：對於開放的API，豆瓣、新浪微博、GitHub，好用，很是合適；對於內部開發，很差用。
基於資源型的RESTFul API 接口粒度和返回結果過於的「粗」，它一般返回的都是完整的數據模型，這對於客戶端很是不友好。但開放API之因此開放，就是由於它不知道你到底須要什麼返回結果，既然不知道，那麼我乾脆都返回給你。這樣的好處是通用，但客戶端很差處理。你只須要一個字段，服務器啪的丟給你十幾個，做爲客戶端開發者你怎麼想？

內部開發因爲需求很是明確，一般來講服務器是不該該簡單粗暴的直接甩資源實體給客戶端的。那RESTFul API就不能接入到內部開發嗎？固然不是，咱們須要靈活一些借鑑RESTFul中的優勢，來設計咱們的內部API。那麼如何簡化，這就不是一篇文章可以說清楚的了，也沒有一個統一的標準，須要本身去琢磨和體會。

最後舉個例子吧，我我的在開發內部接口時會保留絕大多數的REST 特性，但我不會嚴格的只寫增、刪、改、查四個接口。必要的時候，仍是要靈活處理一下。並且錯誤碼、狀態碼這些很是優秀的特性，必須保留。

好了，關於RESTFul咱們就介紹到這裏。特別強調，接口設計是一個很是依賴於經驗和重構的技術活兒，設計接口須要有一些藝術家的天賦（真實體會），你看GitHub的接口就很是的「美」。不要以爲很簡單，真的比寫代碼還難。難道你們不以爲，有時候起名字真的是一件很難的事兒嘛？

本文原創發佈於慕課網 ，轉載請註明出處，謝謝合做！

做者： 7七月 
連接：http://www.imooc.com/article/17650
來源：慕課網
本文原創發佈於慕課網 ，轉載請註明出處，謝謝合做！

 

出處：https://blog.csdn.net/u013063153/article/details/72811976