此次我讓你完全弄懂 RESTful

時間 2020-12-02

標籤 html git github 面試算法 json 微信 restful 架構 app 欄目 HTML 简体版

原文原文鏈接

本文已收錄至 https://github.com/yessimida/yes ，這裏有個人全部文章分類彙總，歡迎 star!html

RESTful 想必你們都耳熟能詳。git

可是爲何要有 RESTful，RESTful 究竟是什麼意思。github

爲何稱之爲 RESTful 架構？面試

我不用 RESTful 不行嗎？算法

什麼樣才叫真正的 RESTful ？json

其實網上 RESTful 的文章有挺多的，不過有些講的糊里糊塗的，並且很大部分都忽略了 HATEOAS。微信

在以前的面試中面試官就問過我，你怎麼理解 RESTful 的，英文全稱是啥？爲何叫這個名字?restful

當時我人都傻了。架構

面試官不講武德，針對我這個剛出社會的小夥子。app

其實有不少人也稀裏糊塗的，也包括我本身。

就面向資源唄，不加動詞咯，還能咋滴，我加動詞不也能用嗎？

並且我以前還特不能理解，爲啥這叫架構？

我特地搜索了下架構的解釋。

軟件架構是有關軟件總體結構與組件的抽象描述，用於指導大型軟件系統各個方面的設計。

總體結構與組件的抽象描述。

RESTful 哪有什麼組件和結構之間的玩意？

因此就至今我寫下這篇文章的時候我也理解不了爲何叫 RESTful 架構。

多是我對架構的理解太狹隘，還不到火候。

我我的只能理解成 RESTful 風格的 API 設計，也就是說 RESTful 只是一種指導風格，就像咱們 Java 要用駝峯命名法。

那不用駝峯命名法代碼就不能跑了嗎？

固然能跑，這只是一種但願你們都能遵循的規範。

對 RESTful 而言我以爲算不上規範，只能說指導風格。

來讓咱們正式的進入對 RESTful 的剖析。

REST

REST 不是一個單詞，是 Representational State Transfer 的縮寫。

直譯過來就是表述性狀態轉移。

我對這個名字蒙了一年多，就不能說點能聽得懂的嘛。

從提出 REST 的論文中我翻了翻，沒有明說可是表達的意思是其實它還有個主語 Resource 。

因此是資源的表述性狀態轉移。

稍微能夠理解一點了。

咱們先無論什麼狀態轉移，大體先有點感受。

知道 REST 以後 RESTful 就不難解釋了，加 ful 就是變形容詞了，好比 wonderful girl。

至此對名字稍微解釋了一下，疑惑還在沒事，我們慢慢理。

REST 的核心

核心就是資源，用 URL 定位資源，用 HTTP 動詞來描述所要作的操做。

HTTP的提供了不少動詞：GET、PUT、POST、DELETE......

這些動詞都是有含義的。

好比 GET 就是獲取資源，是查詢請求。

PUT 指的是修改資源，是冪等的。

POST 也是修改(新增也是一種修改)，指的是不冪等的操做。

因此根據這些規範咱們都能得知此次交互的一些動做，因此正確的使用姿式以下：

好比獲取一個 user。

錯誤姿式：GET /getUserById?userId=1。

正確姿式：GET /users/1。

再好比新增 user。

錯誤姿式：POST /addUser （省略body）。

正確姿式：POST /users （省略body）。

能夠看到 HTTP 的動詞其實就能指代你要對資源作的操做，因此不須要在 URL 上作一些東西，就把 URL 代表的東西就看作一個資源便可。

這裏注意要用對 HTTP 動詞，好比一個獲取資源的請求用 PUT，用了也能獲取資源可是這不合適。

其實更深一步的理解是 HTTP 是一個協議。

協議其實就是約定好的一個東西，協議就規定 GET 是獲取資源，那你非得在 URL 上再重複一遍或者全部請求不論增刪改都用 GET 這個動做，這其實就是沒有徹底遵循這個協議。

能夠說只是把 HTTP 當成一個傳輸管道，而不是約定好的協議。

這實際上是對 HTTP 更深一層的認識，我認爲也是 RESTful 被推出的緣由。

固然理想很豐滿，現實很骨感，仍是有不少人就 getUserById。

不過我我的以爲問題不大，公司統一就行。

HATEOAS

即 Hypermedia as the Engine of Application State 的縮寫，翻譯過來就是做爲應用狀態引擎的超媒體。

這也是 REST 提出的設計。

是否是理解不了？其實很簡單。

例子我就不本身編了，抄一下 stackoverflow 回答上的例子。

好比你請求獲取用戶列表：

GET /users
Accept: application/json+userdb

此時的返回應該是：

200 OK
Content-Type: application/json+userdb

{
    "users": [
        {
            "id": 1,
            "name": "Emil",
            "country: "Sweden",
            "links": [
                {
                    "href": "/user/1",
                    "rel": "self",
                    "method": "GET"
                },
                {
                    "href": "/user/1",
                    "rel": "edit",
                    "method": "PUT"
                },
                {
                    "href": "/user/1",
                    "rel": "delete",
                    "method": "DELETE"
                }
            ]
        },
        {
            "id": 2,
           ....省略.....
        }
    ],
    "links": [
        {
            "href": "/user",
            "rel": "create",
            "method": "POST"
        }
    ]
}

重點就是這個 links，結果會返回你能對這個資源所作的操做。

好比對於 userId 是 1 的，你調用 PUT /user/1就是作修改這個用戶，DELETE /user/1 就是刪除這個用戶。

最外層的 links 告訴你用 POST /user 就能再建立一個用戶。

這裏還有個隱藏信息，可能看到外層的 links 沒有返回 DELETE 的信息，說明此時客戶端沒法刪除用戶！

因此說 RESTful API 還須要在返回此時能作資源所作的操做，這樣客戶端就知道它能作什麼。

它也不須要管具體怎麼作，反正返回裏面會告訴它 DELETE 就這樣這樣，POST 就這樣這樣。

沒告訴它的就是不能作的。

而後這個時候再去理解下資源的表述性狀態轉移，是否是感受來了？

若是說上一 part 提到用 HTTP 的動詞來指代動做， URL 僅表示資源的現實是骨感的。

那麼 HATEOAS 的現實就是灰。

基本上沒幾家公司會這麼作。

就我我的而言這玩意沒啥用。