天天看點

避免自己寫的 url 被diss!建議看看這篇RestFul API簡明教程!

雲栖号資訊:【 點選檢視更多行業資訊

在這裡您可以找到不同行業的第一手的上雲資訊,還在等什麼,快來!

避免自己寫的 url 被diss!建議看看這篇RestFul API簡明教程!

RestFul API 是每個程式員都應該了解并掌握的基本知識,我們在開發過程中設計 API 的時候也應該至少要滿足 RestFul API 的最基本的要求(比如接口中盡量使用名詞,使用 POST 請求建立資源,DELETE 請求删除資源等等,示例:GET /notes/id:擷取某個指定 id 的筆記的資訊)。

如果你看 RestFul API 相關的文章的話一般都比較晦澀難懂,包括我下面的文章也會提到一些概念性的東西。但是,實際上我們平時開發用到的 RestFul API 的知識非常簡單也很容易概括!舉個例子,如果我給你下面兩個 url 你是不是立馬能知道它們是幹什麼的!這就是 RestFul API 的強大之處!

RestFul API 可以你看到 url + http method 就知道這個 url 是幹什麼的,讓你看到了 http 狀态碼(status code)就知道請求結果如何。

GET /classs:列出所有班級

POST /classs:建立一個班級

下面的内容隻是介紹了我覺得關于 RestFul API 比較重要的一些東西,歡迎補充。

一、重要概念

REST,即 REpresentational State Transfer 的縮寫。這個詞組的翻譯過來就是"表現層狀态轉化"。這樣了解起來甚是晦澀,實際上 REST 的全稱是 Resource Representational State Transfe ,直白地翻譯過來就是 “資源”在網絡傳輸中以某種“表現形式”進行“狀态轉移” 。如果還是不能繼續了解,請繼續往下看,相信下面的講解一定能讓你了解到底啥是 REST 。

我們分别對上面涉及到的概念進行解讀,以便加深了解,不過實際上你不需要搞懂下面這些概念,也能看懂我下一部分要介紹到的内容。不過,為了更好地能跟别人扯扯 “RestFul API”我建議你還是要好好了解一下!

  • 資源(Resource) :我們可以把真實的對象資料稱為資源。一個資源既可以是一個集合,也可以是單個個體。比如我們的班級 classs 是代表一個集合形式的資源,而特定的 class 代表單個個體資源。每一種資源都有特定的 URI(統一資源定位符)與之對應,如果我們需要擷取這個資源,通路這個 URI 就可以了,比如擷取特定的班級:/class/12。另外,資源也可以包含子資源,比如 /classs/classId/teachers:列出某個指定班級的所有老師的資訊
  • 表現形式(Representational):"資源"是一種資訊實體,它可以有多種外在表現形式。我們把"資源"具體呈現出來的形式比如 json,xml,image,txt 等等叫做它的"表現層/表現形式"。
  • 狀态轉移(State Transfer) :大家第一眼看到這個詞語一定會很懵逼?内心 BB:這尼瑪是啥啊? 大白話來說 REST 中的狀态轉移更多地描述的伺服器端資源的狀态,比如你通過增删改查(通過 HTTP 動詞實作)引起資源狀态的改變。ps:網際網路通信協定 HTTP 協定,是一個無狀态協定,所有的資源狀态都儲存在伺服器端。

綜合上面的解釋,我們總結一下什麼是 RESTful 架構:

1.每一個 URI 代表一種資源;

2.用戶端和伺服器之間,傳遞這種資源的某種表現形式比如 json,xml,image,txt 等等;

3.用戶端通過特定的 HTTP 動詞,對伺服器端資源進行操作,實作"表現層狀态轉化"。

二、REST 接口規範

1、動作

  • GET :請求從伺服器擷取特定資源。舉個例子:GET /classs(擷取所有班級)
  • POST :在伺服器上建立一個新的資源。舉個例子:POST /classs(建立班級)
  • PUT :更新伺服器上的資源(用戶端提供更新後的整個資源)。舉個例子:PUT /classs/12(更新編号為 12 的班級)
  • DELETE :從伺服器删除特定的資源。舉個例子:DELETE /classs/12(删除編号為 12 的班級)
  • PATCH :更新伺服器上的資源(用戶端提供更改的屬性,可以看做作是部分更新),使用的比較少,這裡就不舉例子了。

2、路徑(接口命名)

路徑又稱"終點"(endpoint),表示 API 的具體網址。實際開發中常見的規範如下:

  • 網址中不能有動詞,隻能有名詞,API 中的名詞也應該使用複數。 因為 REST 中的資源往往和資料庫中的表對應,而資料庫中的表都是同種記錄的"集合"(collection)。如果 API 調用并不涉及資源(如計算,翻譯等操作)的話,可以用動詞。 比如:GET /calculate?

    param1=11&param2=33

  • 不用大寫字母,建議不用中杠 - 不用下杠 _ 比如邀請碼寫成 invitation-code而不是 invitation_code

Talk is cheap!來舉個實際的例子來說明一下吧!現在有這樣一個 API 提供班級(class)的資訊,還包括班級中的學生和教師的資訊,則它的路徑應該設計成下面這樣。

接口盡量使用名詞,禁止使用動詞。 下面是一些例子:

避免自己寫的 url 被diss!建議看看這篇RestFul API簡明教程!

反例:

避免自己寫的 url 被diss!建議看看這篇RestFul API簡明教程!

理清資源的層次結構,比如業務針對的範圍是學校,那麼學校會是一級資源:/schools,老師: /schools/teachers,學生: /schools/students 就是二級資源。

3、過濾資訊(Filtering)

如果我們在查詢的時候需要添加特定條件的話,建議使用 url 參數的形式。比如我們要查詢 state 狀态為 active 并且 name 為 guidegege 的班級:

避免自己寫的 url 被diss!建議看看這篇RestFul API簡明教程!

比如我們要實作分頁查詢:

避免自己寫的 url 被diss!建議看看這篇RestFul API簡明教程!

4、狀态碼(Status Codes)

狀态碼範圍:

避免自己寫的 url 被diss!建議看看這篇RestFul API簡明教程!

三 HATEOAS

RestFul 的極緻是 hateoas ,但是這個基本不會在實際項目中用到。

上面是 RESTful API 最基本的東西,也是我們平時開發過程中最容易實踐到的。實際上,RESTful API 最好做到 Hypermedia,即傳回結果中提供連結,連向其他 API 方法,使得使用者不查文檔,也知道下一步應該做什麼。

比如,當使用者向 api.example.com 的根目錄送出請求,會得到這樣一個文檔。

避免自己寫的 url 被diss!建議看看這篇RestFul API簡明教程!

上面代碼表示,文檔中有一個 link 屬性,使用者讀取這個屬性就知道下一步該調用什麼 API 了。rel 表示這個 API 與目前網址的關系(collection 關系,并給出該 collection 的網址),href 表示 API 的路徑,title 表示 API 的标題,type 表示傳回類型 Hypermedia API 的設計被稱為HATEOAS。

在 Spring 中有一個叫做 HATEOAS 的 API 庫,通過它我們可以更輕松的建立除符合 HATEOAS 設計的 API。

【雲栖号線上課堂】每天都有産品技術專家分享!

課程位址:

https://yqh.aliyun.com/zhibo

立即加入社群,與專家面對面,及時了解課程最新動态!

【雲栖号線上課堂 社群】

https://c.tb.cn/F3.Z8gvnK

原文釋出時間:2020-03-31

本文作者:Guide哥

本文來自:“掘金”,了解相關資訊可以關注“

掘金