點擊上方藍字關注公衆号

　　碼個蛋第276次推文

　　福利就上老婆照片吧

　　作者：SexyCode

　　博客：htt(3)" />

　　面向前台

　　“剛才我們向前台點了一杯拿鐵，這個過程可以用這段文字來描述”，說着，我在紙上寫下了這段JSON，雖然她不知道什麼叫JSON，但理解這段文字對于英語專業8級的她，實在再簡單不過。

　　{"addOrder": {"orderName": "latte"}}

　　“我們通過這段文字，告訴前台，新增一筆訂單，訂單是一杯拿鐵咖啡”，接着，前台給我們返回這麼一串回複：

　　{"orderId": "123456"}

　　“訂單ID？還是訂單編号？”

　　“恩恩，就是訂單編号”

　　“那我們就等着前台喊‘訂單123456的客戶可以取餐了’，然後就可以開吃了！”

　　“哈哈，你真聰明，不過，在這之前，假設我們有一張會員卡，我們想查詢一下這張會員卡的餘額，這時候，要向前台發起另一個詢問”，我繼續在紙上寫着：

　　"queryBalance": {"cardId": "886333"}}

　　“查詢卡号為886333的卡的餘額？”“真棒！接着，查詢的結果返回來了”

　　{"balance": "0"}

　　“切，沒錢......”“哈哈，沒錢，現在我們要跟前台說，這杯咖啡不要了”，我在紙上寫到：

　　{"deleteOrder": {"orderId": "123456"}}

　　“哼，這就把訂單取消啦？”

　　1

　　面向資源

　　“現在這家咖啡店越做越大，來喝咖啡的人越來越多，單靠前台顯然是不行的，店主決定進行分工，每個資源都有專人負責，我們可以直接面向資源操作。”

　　"面向資源？”

　　“是的，比如還是下單，請求的内容不變，但是我們多了一條消息”，我在紙上畫出這次的模型：

　　/orders{"addOrder": {"orderName": "latte"}}

　　“多了一個斜杠和orders？這是什麼意思？”

　　“這個表示我們這個請求是發給哪個資源的，訂單是一種資源，我們可以理解為是咖啡廳專門管理訂單的人，他可以幫我們處理所有有關訂單的操作，包括新增訂單、修改訂單、取消訂單等操作”

　　“Soga...”

　　“接着還是會返回訂單的編号給我們”

　　{"orderId": "123456"}

　　“下面，我們還是要查詢會員卡餘額，這次請求的資源變成了cards”

　　/cards{"queryBalance": {"cardId": "886333"}}

　　“接下來是取消訂單”“這個我會”，說着，她搶走我手上的筆，在紙上寫了起來：

　　/orders{"deleteOrder": {"orderId": "123456"}}

　　2

　　打上标簽

　　“接下來，店主還想繼續優化他的咖啡廳的服務流程，他發現負責處理訂單的員工，每次都要去訂單内容裡面看是新增訂單還是删除訂單，還是其他的什麼操作，十分不方便，于是規定，所有新增資源的請求，都在請求上面寫上大大的‘POST’，表示這是一筆新增資源的請求”

　　“其他種類的請求，比如查詢類的，用‘GET’表示，删除類的，用‘DELETE’表示”

　　“還有修改類的，修改分為兩種，第一種，如果這個修改，無論發送多少次，最後一次修改後的資源，總是和第一次修改後的一樣，比如将拿鐵改為貓屎，那麼用‘PUT’表示；第二種，如果這個修改，每次修改都會讓這個資源和前一次的不一樣，比如是加一杯咖啡，那麼這種請求用‘PATCH’或者‘POST’表示”，一口氣講了這麼多，發現她有點似懂非懂。

　　“來，我們再來重複上面那個過程，來一杯拿鐵”，我邊說邊畫着：

　　POST /orders{"orderName": "latte"}

　　"請求的内容簡潔多啦，不用告訴店員是addOrder，看到POST就知道是新增"，她聽的很認真，理解的也很透徹。

　　"恩恩，返回的内容還是一樣"

　　{"orderId": "123456"}

　　“接着是查詢會員卡餘額，這次也簡化了很多”

　　GET /cards{"cardId": "886333"}

　　“這個請求我們還可以進一步優化為這樣”

　　GET /cards/886333

　　“Soga，直接把要查詢的卡号寫在後面了”“沒錯，接着，取消訂單”

　　DELETE /orders/123456

　　3

　　完美服務

　　“忽然有一天，有個顧客抱怨說，他買了咖啡後，不知道要怎麼取消訂單，咖啡廳一個店員回了一句，你不會看我們的宣傳單嗎，上面不寫着：

　　DELETE /orders/{orderId}

　　顧客反問道，誰會去看那個啊，店員不服，又說到，你瞎了啊你......據說後面兩人吵着吵着還打了起來...”“噗，真是悲劇...”

　　“有了這次教訓，店長決定，顧客下了單之後，不僅給他們返回訂單的編号，還給顧客返回所有可以對這個訂單做的操作，比如告訴用戶如何删除訂單。現在，我們還是發出請求，請求内容和上一次一樣”

　　POST /orders{"orderName": "latte"}

　　“但是這次返回時多了些内容”

　　{"orderId": "123456","link": {"rel": "cancel","url": "/order/123456"}}

　　“這次返回時多了一項link信息，裡面包含了一個rel屬性和url屬性，rel是relationship的意思，這裡的關系是

　　cancel，url則告訴你如何執行這個cancel操作，接着你就可以這樣子來取消訂單啦”

　　DELETE /orders/123456

　　“哈哈，這服務真是貼心，以後再也不用擔心店員和顧客打起來了”

　　“訂單123456的客戶可以取餐了”，伴随着咖啡廳的廣播，我們吃起了下午茶，一杯拿鐵，兩支吸管......

　　4

　　對程序員的話

　　用了大白話，給老婆講明白了RESTful的來龍去脈，當然，我還是有些話想說的，隻是怕老婆聽完一臉懵逼，沒給她說：

　　1、

　　上面講的Level0~Level3，來自Leonard Richardson提出的Richardson Maturity Model：

　　Level0和Level1最大的區别，就是Level1擁有了Restful的第一個特征——面向資源，這對構建可伸縮、分布式的架構是至關重要的。同時，如果把Level0的數據格式換成Xml，那麼其實就是SOAP，SOAP的特點是關注行為和處理，和面向資源的RESTful有很大的不同。

　　Level0和Level1，其實都很挫，他們都隻是把HTTP當做一個傳輸的通道，沒有把HTTP當做一種傳輸協議。

　　Level2，真正将HTTP作為了一種傳輸協議，最直觀的一點就是Level2使用了HTTP動詞，GET/PUT/POST/DELETE/PATCH....,這些都是HTTP的規範，規範的作用自然是重大的，用戶看到一個POST請求，就知道它不是幂等的，使用時要小心，看到PUT，就知道他是幂等的，調用多幾次都不會造成問題，當然，這些的前提都是API的設計者和開發者也遵循這一套規範，确保自己提供的PUT接口是幂等的。

　　Level3，關于這一層，有一個古怪的名詞，叫HATEOAS（Hypertext As The Engine Of Application State），中文翻譯為“将超媒體格式作為應用狀态的引擎”，核心思想就是每個資源都有它的狀态，不同狀态下，可對它進行的操作不一樣。理解了這一層，再來看看REST的全稱，Representational State Transfer，中文翻譯為“表述性狀态轉移”，是不是好理解多了？

　　Level3的Restful API，給使用者帶來了很大的便利，使用者隻需要知道如何獲取資源的入口，之後的每個URI都可以通過請求獲得，無法獲得就說明無法執行那個請求。

　　現在絕大多數的RESTful接口都做到了Level2的層次，做到Level3的比較少。當然，這個模型并不是一種規範，隻是用來理解Restful的工具。所以，做到了Level2，也就是面向資源和使用Http動詞，就已經很Restful了。Restful本身也不是一種規範，我比較傾向于用"風格"來形容它。如果你想深入了解Level3，可以閱讀《Rest in Practice》第五章。

　　2、我跟老婆講的時候，用的數據格式是JSON，但是要強調一點，Restful對數據格式沒有限制，就算你用的是XML或者其他格式，隻要符合上面提到的幾個特征，也算Restful。

　　3、關于如何寫出好的Restful API，阮一峰老師已經寫過一篇非常棒的文章：RESTful API （htthtt

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!