_作者： 阮一峰日期： 2011年9月12日div class=asset-body越來越多的人開始意識到，網站即軟件，而且是一種新型的軟件。/div div id=more class=asset-more這種互聯(lián)網軟件采用客戶端/服務器模式，建立在分布式體系上，通過互聯(lián)網通信，具有高延時（high latency）、高并發(fā)等特點。網站開發(fā)，完全可以采用軟件開發(fā)的模式。但是傳統(tǒng)上，軟件和網絡是兩個不同的領域，很少有交集；軟件開發(fā)主要針對單機環(huán)境，網絡則主要研究系統(tǒng)之間的通信。互聯(lián)網的興起，使得這兩個領域開始融合，現(xiàn)在我們必須考慮，如何開發(fā)在互聯(lián)網環(huán)境中使用的軟件。RESTful架構，就是目前最流行的一種互聯(lián)網軟件架構。它結構清晰、符合標準、易于理解、擴展方便，所以正得到越來越多網站的采用。但是，到底什么是RESTful架構，并不是一個容易說清楚的問題。下面，我就談談我理解的RESTful架構。一、起源REST這個詞，是Roy Thomas Fielding在他2000年的博士論文中提出的。Fielding是一個非常重要的人，他是HTTP協(xié)議（1.0版和1.1版）的主要設計者、Apache服務器軟件的作者之一、Apache基金會的第一任主席。所以，他的這篇論文一經發(fā)表，就引起了關注，并且立即對互聯(lián)網開發(fā)產生了深遠的影響。他這樣介紹論文的寫作目的：本文研究計算機科學兩大前沿-軟件和網絡-的交叉點。長期以來，軟件研究主要關注軟件設計的分類、設計方法的演化，很少客觀地評估不同的設計選擇對系統(tǒng)行為的影響。而相反地，網絡研究主要關注系統(tǒng)之間通信行為的細節(jié)、如何改進特定通信機制的表現(xiàn)，常常忽視了一個事實，那就是改變應用程序的互動風格比改變互動協(xié)議，對整體表現(xiàn)有更大的影響。我這篇文章的寫作目的，就是想在符合架構原理的前提下，理解和評估以網絡為基礎的應用軟件的架構設計，得到一個功能強、性能好、適宜通信的架構。(This dissertation explores a junction on the frontiers of two research disciplines in computer science: software and networking. Software research has long been concerned with the categorization of software designs and the development of design methodologies, but has rarely been able to objectively evaluate the impact of various design choices on system behavior. Networking research, in contrast, is focused on the details of generic communication behavior between systems and improving the performance of particular communication techniques, often ignoring the fact that changing the interaction style of an application can have more impact on performance than the communication protocols used for that interaction. My work is motivated by the desire to understand and evaluate the architectural design of network-based application software through principled use of architectural constraints, thereby obtaining the functional, performance, and social properties desired of an architecture. )二、名稱Fielding將他對互聯(lián)網軟件的架構原則，定名為REST，即Representational State Transfer的縮寫。我對這個詞組的翻譯是表現(xiàn)層狀態(tài)轉化。如果一個架構符合REST原則，就稱它為RESTful架構。要理解RESTful架構，最好的方法就是去理解Representational State Transfer這個詞組到底是什么意思，它的每一個詞代表了什么涵義。如果你把這個名稱搞懂了，也就不難體會REST是一種什么樣的設計。三、資源（Resources）REST的名稱表現(xiàn)層狀態(tài)轉化中，省略了主語。表現(xiàn)層其實指的是資源（Resources）的表現(xiàn)層。所謂資源，就是網絡上的一個實體，或者說是網絡上的一個具體信息。它可以是一段文本、一張圖片、一首歌曲、一種服務，總之就是一個具體的實在。你可以用一個URI（統(tǒng)一資源定位符）指向它，每種資源對應一個特定的URI。要獲取這個資源，訪問它的URI就可以，因此URI就成了每一個資源的地址或獨一無二的識別符。所謂上網，就是與互聯(lián)網上一系列的資源互動，調用它的URI。四、表現(xiàn)層（Representation）資源是一種信息實體，它可以有多種外在表現(xiàn)形式。我們把資源具體呈現(xiàn)出來的形式，叫做它的表現(xiàn)層（Representation）。比如，文本可以用txt格式表現(xiàn)，也可以用HTML格式、XML格式、JSON格式表現(xiàn)，甚至可以采用二進制格式；圖片可以用JPG格式表現(xiàn)，也可以用PNG格式表現(xiàn)。URI只代表資源的實體，不代表它的形式。嚴格地說，有些網址最后的.html后綴名是不必要的，因為這個后綴名表示格式，屬于表現(xiàn)層范疇，而URI應該只代表資源的位置。它的具體表現(xiàn)形式，應該在HTTP請求的頭信息中用Accept和Content-Type字段指定，這兩個字段才是對表現(xiàn)層的描述。五、狀態(tài)轉化（State Transfer）訪問一個網站，就代表了客戶端和服務器的一個互動過程。在這個過程中，勢必涉及到數(shù)據(jù)和狀態(tài)的變化?；ヂ?lián)網通信協(xié)議HTTP協(xié)議，是一個無狀態(tài)協(xié)議。這意味著，所有的狀態(tài)都保存在服務器端。因此，如果客戶端想要操作服務器，必須通過某種手段，讓服務器端發(fā)生狀態(tài)轉化（State Transfer）。而這種轉化是建立在表現(xiàn)層之上的，所以就是表現(xiàn)層狀態(tài)轉化?？蛻舳擞玫降氖侄?，只能是HTTP協(xié)議。具體來說，就是HTTP協(xié)議里面，四個表示操作方式的動詞：GET、POST、PUT、DELETE。它們分別對應四種基本操作：GET用來獲取資源，POST用來新建資源（也可以用于更新資源），PUT用來更新資源，DELETE用來刪除資源。六、綜述綜合上面的解釋，我們總結一下什么是RESTful架構：（1）每一個URI代表一種資源；（2）客戶端和服務器之間，傳遞這種資源的某種表現(xiàn)層；（3）客戶端通過四個HTTP動詞，對服務器端資源進行操作，實現(xiàn)表現(xiàn)層狀態(tài)轉化。七、誤區(qū)RESTful架構有一些典型的設計誤區(qū)。最常見的一種設計錯誤，就是URI包含動詞。因為資源表示一種實體，所以應該是名詞，URI不應該有動詞，動詞應該放在HTTP協(xié)議中。舉例來說，某個URI是/posts/show/1，其中show是動詞，這個URI就設計錯了，正確的寫法應該是/posts/1，然后用GET方法表示show。如果某些動作是HTTP動詞表示不了的，你就應該把動作做成一種資源。比如網上匯款，從賬戶1向賬戶2匯款500元，錯誤的URI是：POST /accounts/1/transfer/500/to/2正確的寫法是把動詞transfer改成名詞transaction，資源不能是動詞，但是可以是一種服務：POST /transaction HTTP/1.1Host: from=1&to=2&amount=500.00另一個設計誤區(qū)，就是在URI中加入版本號：/app/1.0/foo/app/1.1/foo/app/2.0/foo因為不同的版本，可以理解成同一種資源的不同表現(xiàn)形式，所以應該采用同一個URI。版本號可以在HTTP請求頭信息的Accept字段中進行區(qū)分（參見Versioning REST Services）：Accept: vnd.example-com.foo+json; version=1.0Accept: vnd.example-com.foo+json; version=1.1Accept: vnd.example-com.foo+json; version=2.0（完）*RESTful API 設計指南/blog/2014/05/restful_api.html作者： 阮一峰日期： 2014年5月22日div class=asset-body網絡應用程序，分為前端和后端兩個部分。當前的發(fā)展趨勢，就是前端設備層出不窮（手機、平板、桌面電腦、其他專用設備.）。/div div id=more class=asset-more因此，必須有一種統(tǒng)一的機制，方便不同的前端設備與后端進行通信。這導致API構架的流行，甚至出現(xiàn)API First的設計思想。RESTful API是目前比較成熟的一套互聯(lián)網應用程序的API設計理論。我以前寫過一篇理解RESTful架構，探討如何理解這個概念。今天，我將介紹RESTful API的設計細節(jié)，探討如何設計一套合理、好用的API。我的主要參考了兩篇文章（1，2）。一、協(xié)議API與用戶的通信協(xié)議，總是使用HTTPs協(xié)議。二、域名應該盡量將API部署在專用域名之下。如果確定API很簡單，不會有進一步擴展，可以考慮放在主域名下。/api/三、版本（Versioning）應該將API的版本號放入URL。/v1/另一種做法是，將版本號放在HTTP頭信息中，但不如放入URL方便和直觀。Github采用這種做法。四、路徑（Endpoint）路徑又稱終點（endpoint），表示API的具體網址。在RESTful架構中，每個網址代表一種資源（resource），所以網址中不能有動詞，只能有名詞，而且所用的名詞往往與數(shù)據(jù)庫的表格名對應。一般來說，數(shù)據(jù)庫中的表都是同種記錄的集合（collection），所以API中的名詞也應該使用復數(shù)。舉例來說，有一個API提供動物園（zoo）的信息，還包括各種動物和雇員的信息，則它的路徑應該設計成下面這樣。 /v1/zoos /v1/animals /v1/employees五、HTTP動詞對于資源的具體操作類型，由HTTP動詞表示。常用的HTTP動詞有下面五個（括號里是對應的SQL命令）。 GET（SELECT）：從服務器取出資源（一項或多項）。 POST（CREATE）：在服務器新建一個資源。 PUT（UPDATE）：在服務器更新資源（客戶端提供改變后的完整資源）。 PATCH（UPDATE）：在服務器更新資源（客戶端提供改變的屬性）。 DELETE（DELETE）：從服務器刪除資源。還有兩個不常用的HTTP動詞。 HEAD：獲取資源的元數(shù)據(jù)。 OPTIONS：獲取信息，關于資源的哪些屬性是客戶端可以改變的。下面是一些例子。 GET /zoos：列出所有動物園 POST /zoos：新建一個動物園 GET /zoos/ID：獲取某個指定動物園的信息 PUT /zoos/ID：更新某個指定動物園的信息（提供該動物園的全部信息） PATCH /zoos/ID：更新某個指定動物園的信息（提供該動物園的部分信息） DELETE /zoos/ID：刪除某個動物園 GET /zoos/ID/animals：列出某個指定動物園的所有動物 DELETE /zoos/ID/animals/ID：刪除某個指定動物園的指定動物六、過濾信息（Filtering）如果記錄數(shù)量很多，服務器不可能都將它們返回給用戶。API應該提供參數(shù)，過濾返回結果。下面是一些常見的參數(shù)。 ?limit=10：指定返回記錄的數(shù)量 ?offset=10：指定返回記錄的開始位置。 ?page=2&per_page=100：指定第幾頁，以及每頁的記錄數(shù)。 ?sortby=name&order=asc：指定返回結果按照哪個屬性排序，以及排序順序。 ?animal_type_id=1：指定篩選條件參數(shù)的設計允許存在冗余，即允許API路徑和URL參數(shù)偶爾有重復。比如，GET /zoo/ID/animals 與 GET /animals?zoo_id=ID 的含義是相同的。七、狀態(tài)碼（Status Codes）服務器向用戶返回的狀態(tài)碼和提示信息，常見的有以下一些（方括號中是該狀態(tài)碼對應的HTTP動詞）。 200 OK - GET：服務器成功返回用戶請求的數(shù)據(jù)，該操作是冪等的（Idempotent）。 201 CREATED - POST/PUT/PATCH：用戶新建或修改數(shù)據(jù)成功。 202 Accepted - *：表示一個請求已經進入后臺排隊（異步任務） 204 NO CONTENT - DELETE：用戶刪除數(shù)據(jù)成功。 400 INVALID REQUEST - POST/PUT/PATCH：用戶發(fā)出的請求有錯誤，服務器沒有進行新建或修改數(shù)據(jù)的操作，該操作是冪等的。 401 Unauthorized - *：表示用戶沒有權限（令牌、用戶名、密碼錯誤）。 403 Forbidden - * 表示用戶得到授權（與401錯誤相對），但是訪問是被禁止的。 404 NOT FOUND - *：用戶發(fā)出的請求針對的是不存在的記錄，服務器沒有進行操作，該操作是冪等的。 406 Not Acceptable - GET：用戶請求的格式不可得（比如用戶請求JSON格式，但是只有XML格式）。 410 Gone -GET：用戶請求的資源被永久刪除，且不會再得到的。 422 Unprocesable entity - POST/PUT/PATCH 當創(chuàng)建一個對象時，發(fā)生一個驗證錯誤。 500 INTERNAL SERVER ERROR - *：服務器發(fā)生錯誤，用戶將無法判斷發(fā)出的請求是否成功。狀態(tài)碼的完全列表參見這里。八、錯誤處理（Error handling）如果狀態(tài)碼是4xx，就應該向用戶返回出錯信息。一般來說，返回的信息中將error作為鍵名，出錯信息作為鍵值即可。 error:Invalid API key九、返回結果針對不同操作，服務器向用戶返回的結果應該符合以下規(guī)范。 GET /collection：返回資源對象的列表（數(shù)組） GET /collection/resource：返回單個資源對象 POST /collection：返回新生成的資源對象 PUT /collection/resource：返回完整的資源對象 PATCH /collection/resource：返回完整的資源對象 DELETE /collection/resource：返回一個空文檔十、Hypermedia APIRESTful API最好做到Hypermedia，即返回結果中提供鏈接，連向其他API方法，使得用戶不查文檔，也知道下一步應該做什么。比如，當用戶向的根目錄發(fā)出請求，會得到這樣一個文檔。link: rel: collection /zoos, href:/zoos, title:List of zoos, type:application/vnd.yourformat+json上面代碼表示，文檔中有一個link屬性，用戶讀取這個屬性就知道下一步該調用什么API了。rel表示這個API與當前網址的關系（collection關系，并給出該collection的網址），href表示API的路徑，title表示API的標題，type表示返回類型。Hypermedia API的設計被稱為HATEOAS。Github的API就是這種設計，訪問會得到一個所有可用API的網址列表。 current_user_url:/user, authorizations_url:/authorizations, / .從上面可以看到，如果想獲取當前用戶的信息，應該去訪問/user，然后就得到了下面結果。 message:Requires authentication, documentation_url:/v3上面代碼表示，服務器給出了提示信息，以及文檔的網址。十一、其他（1）API的身份認證應該使用OAuth 2.0框架。（2）服務器返回的數(shù)據(jù)格式，應該盡量使用JSON，避免使用XML。（完）/div*Web API已經在最近幾年變成重要的話題，一個干凈的API設計對于后端系統(tǒng)是非常重要的。通常我們?yōu)閃eb API使用RESTful設計，REST概念分離了API結構和邏輯資源，通過Http方法GET, DELETE, POST 和 PUT來操作資源。下面是進行RESTful Web API十個最佳實踐，能為你提供一個良好的API設計風格。1.使用名詞而不是動詞Resource資源GET讀POST創(chuàng)建PUT修改DELETE/cars返回 cars集合創(chuàng)建新的資源批量更新cars刪除所有cars/cars/711返回特定的car該方法不允許(405)更新一個指定的資源擅長指定資源不要使用：/getAllCars/createNewCar/deleteAllRedCars2.Get方法和查詢參數(shù)不應該涉及狀態(tài)改變使用PUT, POST和DELETE方法而不是GET方法來改變狀態(tài)，不要使用GET進行狀態(tài)改變:GET /users/711?activateGET /users/711/activate3.使用復數(shù)名詞不要混淆名詞單數(shù)和復數(shù)，為了保持簡單，只對所有資源使用復數(shù)。/cars 而不是 /car/users 而不是 /user/products 而不是 /product/settings 而部署 /setting4. 使用子資源表達關系如果一個資源與另外一個資源有關系，使用子資源：GET /cars/711/drivers/ 返回 car 711的所有司機GET /cars/711/drivers/4 返回 car 711的4號司機5.使用Http頭聲明序列化格式在客戶端和服務端，雙方都要知道通訊的格式，格式在HTTP-Header中指定Content-Type 定義請求格式Accept 定義系列可接受的響應格式6.使用HATEOASHypermediaastheEngineofApplicationState 超媒體作為應用狀態(tài)的引擎，超文本鏈接可以建立更好的文本瀏覽： id: 711, manufacturer: bmw, model: X5, seats: 5, drivers: id: 23, name: Stefan Jauker, links: rel: self, href: /api/v1/drivers/23 注意href指向下一個URL7.為集合提供過濾 排序 選擇和分頁等功能Filtering過濾:使用唯一的查詢參數(shù)進行過濾：GET /cars?color=red 返回紅色的carsGET /cars?seats=2 返回小于兩座位的cars集合Sorting排序:允許針對多個字段排序GET /cars?sort=-manufactorer,+model這是返回根據(jù)生產者降序和模型升序排列的car集合Field selection移動端能夠顯示其中一些字段，它們其實不需要一個資源的所有字段，給API消費者一個選擇字段的能力，這會降低網絡流量，提高API可用性。GET /cars?fields=manufacturer,model,id,colorPaging分頁使用 limit 和offset.實現(xiàn)分頁，缺省limit=20 和o