RESTful API設(shè)計怎么理解

這篇文章主要介紹“RESTful API設(shè)計怎么理解”，在日常操作中，相信很多人在RESTful API設(shè)計怎么理解問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”RESTful API設(shè)計怎么理解”的疑惑有所幫助！接下來，請跟著小編一起來學(xué)習(xí)吧！

在完全深入RESTful API設(shè)計之前，詳細了解RESTful API設(shè)計者的工作細節(jié)很重要。

APIs之間不是孤立的，對于API中已經(jīng)存在的應(yīng)用或者服務(wù)的API，新的API要和它們在功能上獨立開來。在我看來，API設(shè)計者的職責(zé)是雙重的：

1. 足夠理解新建API在應(yīng)用中的重要細節(jié)，這樣你就能決定哪些功能需要暴露、如何暴露，以及哪些功能可以排除。

2. 對API中的功能建模，要能解決出現(xiàn)的所有使用場景，同時盡可能遵守RESTful原則。

RESTful API設(shè)計中涉及到3個不同的組件：應(yīng)用、API代碼和客戶端。下圖描述了組件間的相互關(guān)系：

應(yīng)用

應(yīng)用和為它提供的API之間要相互獨立。也許應(yīng)用是GUI程序，你需要為它提供可編程接口。也許應(yīng)用只能通過你設(shè)計的API訪問。

和其它任何應(yīng)用一樣，需要設(shè)計API的應(yīng)用也有它自己的狀態(tài)?！盃顟B(tài)”是動態(tài)的，執(zhí)行很多操作后狀態(tài)會改變。狀態(tài)和狀態(tài)上的操作，應(yīng)該被建模并暴露到API中。

理解應(yīng)用狀態(tài)的最簡單方法是把它描述成應(yīng)用數(shù)據(jù)模型（application data model），可以表示成實體-關(guān)系圖（ER圖）。實體-關(guān)系圖能列出應(yīng)用狀態(tài)中實體的細節(jié)，以及它們間的關(guān)系。

一些情景中，很容易創(chuàng)建實體-關(guān)系圖。假設(shè)一個web應(yīng)用把所有狀態(tài)存在數(shù)據(jù)庫中，我們很容易從數(shù)據(jù)的schema中得到關(guān)系圖。其它一些沒有嚴(yán)格定義的情景下，API設(shè)計者的工作會難一些。這時，為應(yīng)用創(chuàng)建ER圖就真的很有用。對你來說這是難得的鍛煉機會，它幫助你更好地理解應(yīng)用。更重要的是，它會幫你設(shè)計出更好的RESTful API。我們一會詳細討論這個。以后的例子中，我都假設(shè)我們已經(jīng)有了實體-關(guān)系圖（ER diagram）。

除了理解應(yīng)用的狀態(tài)和狀態(tài)上的操作外，你還需要應(yīng)用程序的入口（entry point），它讓你能獲取和更改應(yīng)用狀態(tài)。這個“入口”完全由應(yīng)用決定，可以有多種形式。我們把這個入口稱為應(yīng)用程序接口（ application interface），它的正式稱呼是API。不同的是接口不用于外部消費甚至完全沒有文檔記錄（譯者注：正規(guī)軟件開發(fā)中代碼規(guī)范也是要求寫API文檔的）。為了不產(chǎn)生疑惑，我們不會把接口稱為API，API這個術(shù)語保留給我們將要設(shè)計的RESTful API。

API代碼

API代碼的任務(wù)是通過應(yīng)用接口獲取應(yīng)用的狀態(tài)，同時提供狀態(tài)上的操作，把應(yīng)用接口暴露成RESTful API。在應(yīng)用程序接口和RESTful API之間有一個轉(zhuǎn)換步驟：適配應(yīng)用數(shù)據(jù)模型，并且符合RESTful風(fēng)格。

轉(zhuǎn)換的結(jié)果是形成RESTful風(fēng)格的資源、資源上的操作以及資源之間的關(guān)系。（譯者注：API中只有狀態(tài)的概念，RESTful后形成資源的概念）我們把這些稱為RESTful資源模型（RESTful resource model）。

資源是任何RESTful API的基礎(chǔ)，我們會在resources中詳細介紹?，F(xiàn)在，我們只需要把資源理解成ER圖中的實體（這也是為什么應(yīng)用中沒有實體時我建議你畫ER圖）。

資源間的關(guān)系通過超鏈接表示。這一點也是設(shè)計RESTful API的基本原則（fundamental principles）。資源通常響應(yīng)有限的操作（通常4個），這也是RESTful架構(gòu)的第二個風(fēng)格。

當(dāng)把應(yīng)用模型對象轉(zhuǎn)換成RESTful里的資源時，下面兩個工具函數(shù)很有用：

• to_resource()：從應(yīng)用模型中獲取一個對象，然后轉(zhuǎn)換成資源。

• from_resource()：把資源轉(zhuǎn)換成應(yīng)用模型中的對象。

后面不會再討論這兩個函數(shù)，當(dāng)應(yīng)用數(shù)據(jù)模型和資源模型相似時，函數(shù)會很簡單；不相似的話會很復(fù)雜。

客戶端

客戶端通過標(biāo)準(zhǔn)HTTP協(xié)議消費RESTful API。理論上，RESTful API也可以在其它協(xié)議之上提供。但是，由于HTTP協(xié)議非常廣泛，把RESTful API映射到另一種協(xié)議在真實場景中意義不大。因此，本文僅限于用HTTP協(xié)議相關(guān)術(shù)語描述RESTful協(xié)議。

客戶端通常使用HTTP庫來訪問RESTful API。HTTP已經(jīng)成為一個相對復(fù)雜的協(xié)議，許多目標(biāo)平臺/語言都有優(yōu)秀的庫。因此使用這些庫很合理。

在某些情況下，可能有必要在HTTP庫之上使用通用的REST庫。但是，由于RESTful API中有一些不一致的約定，因此通用的REST庫適用于特定情況下的API。

到此，關(guān)于“RESTful API設(shè)計怎么理解”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識，請繼續(xù)關(guān)注億速云網(wǎng)站，小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>