摘要：但是遠遠不僅是指的風格，它是一種網(wǎng)絡(luò)應(yīng)用的架構(gòu)風格。參考用定位資源在架構(gòu)風格中，用來指定一個資源。完整狀態(tài)碼列表如何設(shè)計在過去不使用架構(gòu)風格的時候，如果我們要設(shè)計一個系統(tǒng)，會以操作為出發(fā)點，然后圍繞它去建設(shè)其他需要的東西。

作為Web開發(fā)者，你可能或多或少了解一些REST的知識，甚至已經(jīng)非常習慣于它，以至于在正式地學習REST的時候，你可能心里會想：“本來就是這樣做的啊，不然還能怎么做呢？”
確實是這樣，REST已經(jīng)成為Web世界的一種內(nèi)在架構(gòu)原則。這主要是因為REST的產(chǎn)生確實與HTTP有著密不可分的聯(lián)系。REST的提出者Roy Fielding在Web界是一位舉足輕重的人物，他是HTTP協(xié)議（1.0版和1.1版）的主要設(shè)計者、Apache服務(wù)器軟件的作者之一、Apache基金會的第一任主席……Fielding在幾年以后回顧起REST的設(shè)計過程時，他說道：

Throughout the HTTP standardization process, I was called on to defend the design choices of the Web. That is an extremely difficult thing to do within a process that accepts proposals from anyone on a topic that was rapidly becoming the center of an entire industry. I had comments from well over 500 developers, many of whom were distinguished engineers with decades of experience, and I had to explain everything from the most abstract notions of Web interaction to the finest details of HTTP syntax. That process honed my model down to a core set of principles, properties, and constraints that are now called REST.

在HTTP標準化的過程中，F(xiàn)ielding作為作者之一，負責向外界對HTTP的設(shè)計作出解釋和辯護。在這個過程中，他的思維模型受到不斷地錘煉，一套準則從中沉淀了下來，這就是REST。

本篇文章的寫作目的是，與讀者一起了解REST的內(nèi)在，認識REST的優(yōu)勢，而不再將它當作是“理所當然”。

REST是Representational State Transfer(在表示層上的狀態(tài)傳輸)的縮寫，這個詞的字面意思要在文章的后面才能解釋清楚。REST是一種WEB應(yīng)用的架構(gòu)風格，它被定義為6個限制，滿足這6個限制，能夠獲得諸多優(yōu)勢（詳細優(yōu)點在文章最后總結(jié)）。

先用一句話來概括RESTful API(具有REST風格的API): 用URL定位資源，用HTTP動詞（GET,HEAD,POST,PUT,PATCH,DELETE）描述操作，用響應(yīng)狀態(tài)碼表示操作結(jié)果。

但是REST遠遠不僅是指API的風格，它是一種網(wǎng)絡(luò)應(yīng)用的架構(gòu)風格。我們到后面會有所體會。
另外，需要注意的是，REST的原則不僅僅適用于HTTP協(xié)議。但是，由于REST的應(yīng)用場景絕大部分是WEB應(yīng)用，本篇文章將基于HTTP來討論REST。

我們?yōu)g覽一個網(wǎng)站，說到底就是與這個網(wǎng)站中的資源進行互動（獲取、提交、更新、刪除）。前端的工作，就是為用戶從服務(wù)端獲取資源、展示資源、請求服務(wù)端改變資源。

RESTful API有助于客戶端和服務(wù)端的功能分離，服務(wù)器完全扮演著一個“資源服務(wù)商”的角色。各種不同的客戶端都可以通過一致的API與這個“資源服務(wù)商”交流，從而與資源進行互動。

在REST架構(gòu)中，“資源”扮演者主要角色。它具有以下特點：

資源是任何可以操作（獲取、提交、更新、刪除）的數(shù)據(jù)，比如一個文檔（document）、一張圖片……

wikipedia: "Web resources" were first defined on the World Wide Web as documents or files identified by their URLs. However, today they have a much more generic and abstract definition that encompasses every thing or entity that can be identified, named, addressed, or handled, in any way whatsoever, on the web. “資源”包括Web中任何可以被標識、命名、定位、處理的事物。

資源的集合也是一種資源，比如blogs表示博客（資源）的集合。

進行資源操作的時候，用URI來指定被操作的資源。如果一個URI不僅能標識一個網(wǎng)絡(luò)上的資源，還能夠定位這個資源，那么這個URI也叫URL。

資源是一個抽象的概念，資源無法被傳輸，只能傳輸資源的表示（representation）。一個資源可以有多種表示，比如，一個資源可以用HTML、XML、JSON來表示。具體傳輸哪種表示取決于服務(wù)端的能力和客戶端的要求。傳輸?shù)谋硎疚幢鼐褪欠?wù)器存儲時使用的表示，比如，這個資源在服務(wù)器不是以HTML或XML或JSON來存儲的，可能是一種更加利于壓縮的表示。總的來說，“表示”是“資源”的存儲和傳輸形式，“資源”是“表示”的內(nèi)容（抽象概念）。不管用什么形式來表示，始終描述的是這個資源。

舉一個例子，當我們討論“文章列表”這個資源時，我們并不在乎它是json格式還是xml格式，我們指的是它的含義：某個用戶的所有文章。但是當我們真的要在服務(wù)器與客戶端之間傳輸數(shù)據(jù)的時候，不能直接“傳輸資源”，因為資源太抽象了，發(fā)送方必須要以某一種表示（representation）來傳遞它（比如json），接收方才能很好地解析和處理。

表示（representation）包括數(shù)據(jù)（data，表示資源本身）和元數(shù)據(jù)（metadata，用于描述這個representation）。在Roy Fielding的論文中有這個定義：A representation is a sequence of bytes, plus representation metadata to describe those bytes.

在前面的例子中，嚴格來說，“json字符串”并不是完整的representation，整個HTTP響應(yīng)才是representation。HTTP body中的是數(shù)據(jù)，HTTP header中的是元數(shù)據(jù)（尤其是Content-Type這種字段）。

參考 https://restfulapi.net/

在RESTful架構(gòu)風格中，URL用來指定一個資源。資源就是服務(wù)器上可操作的實體（可以理解為數(shù)據(jù)）。比如說URL/api/users表示的是該網(wǎng)站的所有用戶，這是一種資源，可以與之互動（獲取、提交、更新、刪除）。另外，資源地址具有層次結(jié)構(gòu)，比如/api/users/csr表示用戶名為"csr"的用戶，/api/users/csr/blogs表示"csr"的所有博客，/api/users/csr/blogs/1234567表示其中的某一篇博客。這些都是資源，后者嵌套在前者之中。

既然URL表示一個資源，自然就不應(yīng)該包含動詞，它應(yīng)該由名詞組成。一個 not RESTful 的例子是通過向api/delete/resource發(fā)送GET請求來刪除一個資源。

更詳細的URL設(shè)計可以查看阮一峰的"RESTful API 設(shè)計指南"或者知乎高票回答。URL風格只是REST的外表，不是本文的重點。

既然通過URL能夠指定一個服務(wù)器上的資源。那么我們應(yīng)該如何與這個資源進行互動呢？我們對這個資源(URL)使用不同的HTTP方法，就代表對這個資源的不同操作：

GET（SELECT）：從服務(wù)器獲取資源（一個資源或資源集合）。

POST（CREATE）：在服務(wù)器新建一個資源（也可以用于更新資源）。

PUT（UPDATE）：在服務(wù)器更新資源（客戶端提供改變后的完整資源）。

PATCH（UPDATE）：在服務(wù)器更新資源（客戶端提供改變的部分）。

DELETE（DELETE）：從服務(wù)器刪除資源。

HEAD：獲取資源的元數(shù)據(jù)。

OPTIONS：獲取信息，關(guān)于資源的哪些屬性是客戶端可以改變的。

GET、HEAD、PUT、DELETE方法是冪等方法(對于同一個內(nèi)容的請求，發(fā)出n次的效果與發(fā)出1次的效果相同)。
GET、HEAD方法是安全方法(不會造成服務(wù)器上資源的改變)。

PATCH不一定是冪等的。PATCH的實現(xiàn)方式有可能是"提供一個用來替換的數(shù)據(jù)"，也有可能是"提供一個更新數(shù)據(jù)的方法"(比如data++)。如果是后者，那么PATCH不是冪等的。

參考：HTTP Methods for RESTful Services

雖然HTTP狀態(tài)碼設(shè)計的本意就是表示操作結(jié)果，但是有時候人們往往沒有很好的利用它，RESTful API要求充分利用HTTP狀態(tài)碼

200 OK - [GET]：服務(wù)器成功返回用戶請求的數(shù)據(jù)，該操作是冪等的（Idempotent）。
201 CREATED - [POST/PUT/PATCH]：用戶新建或修改數(shù)據(jù)成功。
202 Accepted - [*]：表示一個請求已經(jīng)進入后臺排隊（異步任務(wù)）
204 NO CONTENT - [DELETE]：用戶刪除數(shù)據(jù)成功。
400 INVALID REQUEST - [POST/PUT/PATCH]：用戶發(fā)出的請求有錯誤，服務(wù)器沒有進行新建或修改數(shù)據(jù)的操作，該操作是冪等的。
401 Unauthorized - [*]：表示用戶沒有權(quán)限（令牌、用戶名、密碼錯誤）。
403 Forbidden - [*] 表示用戶得到授權(quán)（與401錯誤相對），但是訪問是被禁止的。
404 NOT FOUND - [*]：用戶發(fā)出的請求針對的是不存在的記錄，服務(wù)器沒有進行操作，該操作是冪等的。
406 Not Acceptable - [GET]：用戶請求的格式不可得（比如用戶請求JSON格式，但是只有XML格式）。
410 Gone -[GET]：用戶請求的資源被永久刪除，且不會再得到的。
422 Unprocesable entity - [POST/PUT/PATCH] 當創(chuàng)建一個對象時，發(fā)生一個驗證錯誤。
500 INTERNAL SERVER ERROR - [*]：服務(wù)器發(fā)生錯誤，用戶將無法判斷發(fā)出的請求是否成功。

完整狀態(tài)碼列表

在過去不使用RESTful架構(gòu)風格的時候，如果我們要設(shè)計一個系統(tǒng)，會以“操作”為出發(fā)點，然后圍繞它去建設(shè)其他需要的東西。
舉個例子，我們要向系統(tǒng)中增加一個用戶登陸的功能：

需要一個用戶登陸的功能(操作)

約定一個用于登錄的API(也就是URL)

約定這個API的使用方式(發(fā)送響應(yīng)什么數(shù)據(jù)、格式是什么)

前后端針對這個API進行開發(fā)

這種設(shè)計方式有如下缺點：

當我們不斷為這個系統(tǒng)增加操作，每增加一個操作都要按照上面的流程設(shè)計一次，第2和3點的工作實際是可以大大削減的(通過REST)。

操作之間可能是有依賴的，依賴多起來，系統(tǒng)會變得很復雜。

我們的API缺乏一致性(需要一份龐大的文檔來記錄api的地址、使用方式)。

操作通常被認為是有副作用（Side Effect）的，很難使用緩存技術(shù)。

而如果我們設(shè)計REST風格的系統(tǒng)，資源是第一位的考慮，首先從資源的角度進行系統(tǒng)的拆分、設(shè)計，而不是像以往一樣以操作為角度來進行設(shè)計。

用兩個例子來說明：銀行的轉(zhuǎn)賬API，即時通訊軟件中發(fā)送消息的API。

這兩個功能非常具有“動作性”，看起來和“資源”聯(lián)系不大，很容易就會設(shè)計成not RESTful的API：POST /transfer/${amount}/to/${toUserID}、POST /api/sendMessage。
一旦在URL中引入了動詞，這個URL的功能就定死了，無法用于別的用途（比如，GET /transfer/${amount}/to/${toUserID}或GET /api/sendMessage的語義很奇怪，不好使用）。并且，不同功能的API有各自的結(jié)構(gòu)，一致性很差，需要一份詳細的API文檔才能使用。

這種情況下，要如何通過RESTful架構(gòu)風格，設(shè)計一套一致、多用途的URL呢？
簡單地說，就是將一個“動作”理解為“操作一個資源”。這里的“操作”是指HTTP的方法。

對于轉(zhuǎn)賬動作，就可以理解為“新建一個轉(zhuǎn)賬事務(wù)”（轉(zhuǎn)賬事務(wù)是資源），因此API就可以設(shè)置成這樣: POST /transactions，請求體為：to=632&amount=500。這樣的設(shè)計不但簡潔明了，而且我們可以將這個URL用于別的用途：通過GET /transactions來獲取該用戶的所有轉(zhuǎn)賬事務(wù)。還可以將GET /transactions/456828定義為“獲取某一次轉(zhuǎn)賬記錄”。

即時通訊軟件中發(fā)送消息的動作，我們可以理解為“操作聊天記錄（聊天記錄是資源，它是由“消息”組成的集合，消息也是資源）”，所以API設(shè)計為

POST /messages # 創(chuàng)建新的聊天記錄（body傳輸消息的內(nèi)容）
GET /messages # 獲取聊天記錄（返回一個數(shù)組，其中每個項是一個消息）
GET /messages/${messageID} # 獲取某個消息的詳細信息
PUT /messages/${messageID} # 更新某個消息（body傳輸消息的內(nèi)容）
DELETE /messages/${messageID} # 刪除某個消息的記錄

同理，論壇類應(yīng)用發(fā)帖、回帖的API也可以這樣設(shè)計。

從以上的兩個例子我們可以看出，使用RESTful風格可以克服傳統(tǒng)架構(gòu)風格的那4個缺陷：

設(shè)計API工作量減少，因為功能需求一旦出來，需要操作的資源、操作的方式立刻就能分析出來，因此資源URL和API的使用方式(GET, POST...)都很容易得到。

沒有了操作之間的依賴。資源之間雖然可能有關(guān)聯(lián)，但是小得多。

對資源的操作也就那么幾種(獲取、新建、修改、刪除)，API的一致性、自我描述性很強，不需要過多解釋。

對于GET請求，我們都可以考慮使用緩存，因為在RESTful的架構(gòu)中，GET請求代表獲取數(shù)據(jù)，必須是安全、冪等的。

根據(jù)REST的架構(gòu)限制，RESTful的服務(wù)器必須是無狀態(tài)的，這意味著來自客戶的每一個請求必須包含服務(wù)器處理該請求所需的所有信息， 服務(wù)器不能利用任何已經(jīng)存儲的“上下文(context，在這里表示用戶的會話狀態(tài))”來處理新到來的請求，會話狀態(tài)只能由客戶端來保存，并且在請求時一并提供。

這里注意兩點。1. 服務(wù)器不能存儲“上下文”不代表連數(shù)據(jù)庫都不能有，“上下文”指那些在服務(wù)器內(nèi)存中的、非持久化的數(shù)據(jù)。2. 無狀態(tài)不代表不能有會話(sessions)，無狀態(tài)僅僅指服務(wù)器無狀態(tài)。服務(wù)器不記錄、維護會話，但是會話狀態(tài)可以由客戶端在每次請求的時候提供。

我一開始以為無狀態(tài)與用戶登陸是沖突的，后來在Do sessions really violate RESTfulness? - StackOverflow上找到了一個令我滿意的解答。以下兩幅圖摘錄自這個答案。
無狀態(tài)的認證機制：

What you need is storing username and password on the client and send it with every request. You don"t need more to do this than HTTP basic auth and an encrypted connection.
只需要將用戶名和密碼存儲在客戶端，然后客戶端每次發(fā)送請求都附帶上用戶名和密碼。要做到這點你只需要HTTP基本認證（簡單來說就是將用戶名和密碼放在HTTP頭部）和一個加密的連接(HTTPS)。
如果每次認證，都要去數(shù)據(jù)庫查詢用戶的信息來核對，那么響應(yīng)會非常慢，而且服務(wù)器也會有很大的性能損失。為了加快認證的速度，最好在內(nèi)存中使用認證緩存。這并不違背“無狀態(tài)”的限制，因為緩存的作用僅僅起加速的作用，沒有緩存照樣能工作。

無狀態(tài)的第三方鑒權(quán)機制：

What about 3rd party clients? They cannot have the username and password and all the permissions of the users. So you have to store separately what permissions a 3rd party client can have by a specific user. So the client developers can register they 3rd party clients, and get an unique API key and the users can allow 3rd party clients to access some part of their permissions. Like reading the name and email address, or listing their friends, etc... After allowing a 3rd party client the server will generate an access token. These access token can be used by the 3rd party client to access the permissions granted by the user.
通過這個方式，用戶可以給第三方應(yīng)用授權(quán)，讓第三方應(yīng)用拿著用戶的“令牌”訪問網(wǎng)站的一些服務(wù)。
以上兩幅圖講的是RESTful風格的身份認證機制。在實踐中最好使用OAuth 2.0框架。

無狀態(tài)增強了系統(tǒng)的故障恢復能力，因為在服務(wù)器上沒有保存session的狀態(tài)，所以恢復起來更容易。
更重要的是，無狀態(tài)意味著分布式系統(tǒng)能夠更好地工作，負載均衡器可以自由地將請求分發(fā)到任意的服務(wù)器。因為請求中都已經(jīng)包含了服務(wù)器所需的所有信息，任何服務(wù)器都可以處理。
不僅僅是服務(wù)器，代理、網(wǎng)關(guān)、防火墻也可以理解消息，從而可以在不修改接口的情況下，增加更多強大的功能（比如代理緩存）。
并且，無狀態(tài)讓系統(tǒng)的橫向拓展能力強大。因為不需要在不同的服務(wù)器之間同步session狀態(tài)，所以服務(wù)器之間的溝通開銷很低。增加服務(wù)器的數(shù)量不會帶來明顯的性能損失（“1+1”更接近于“2”了）。

需要注意的是，REST不是一個“宗教”。在你自己的應(yīng)用中，遵循REST的同時應(yīng)該保持合適的尺度。通過權(quán)衡利弊，選擇總體效益最大的方案，即使這個方案有可能“稍微違反REST的原則”。詳見"REST is not a religion..." - stackoverflow

圖片來自steps toward the glory of REST。

前面已經(jīng)討論了level 1和level 2，實際上REST還有一個更高的層次：HATEOAS(Hypermedia As The Engine Of Application State)。

對于客戶端的資源請求，服務(wù)器不僅要返回所請求的資源，而且要返回客戶端所處的狀態(tài)和可轉(zhuǎn)移的狀態(tài)。（客戶端有狀態(tài)）

狀態(tài)可以簡單地理解為客戶端展示的數(shù)據(jù)。可以把客戶端比喻成一個狀態(tài)機，那么這個狀態(tài)機跳轉(zhuǎn)到一個新的狀態(tài)，就會顯示新的內(nèi)容。“首頁”“文章列表”“某篇文章”就是三種客戶端狀態(tài)。

客戶端不需要提前知道應(yīng)用有哪些狀態(tài)，而是根據(jù)服務(wù)端響應(yīng)的“可轉(zhuǎn)移的狀態(tài)”，提供給用戶選擇，從而發(fā)生狀態(tài)轉(zhuǎn)移。

用簡單的話來說，在嚴格的RESTful架構(gòu)中，客戶端不需要提前知道服務(wù)端的API有哪些、怎么調(diào)用，在客戶端與服務(wù)器通信的過程中，服務(wù)端會告訴客戶端：在你當前所處的狀態(tài)下，有哪些API可以使用、可以轉(zhuǎn)移到哪些狀態(tài)。

既然服務(wù)器是無狀態(tài)的，那么它要如何知道發(fā)起請求的用戶處于什么狀態(tài)呢？這就要求客戶端在發(fā)送請求的時候要攜帶上足夠的信息，讓服務(wù)器能夠判斷客戶端所處的狀態(tài)。

這就很像10086的“電話自動語音應(yīng)答服務(wù)”：你想要查詢你的手機流量，只需要會撥打“10086”，對方會提示你按下哪些按鍵就能進入哪些狀態(tài)。進入下一個狀態(tài)以后，又會有語音提示你接下來能夠按哪些按鍵……最終，你能進入到你想要的那個狀態(tài)（流量查詢服務(wù)）。你需要記住的僅僅是“10086”這個號碼而已！

10086的語音提示相當于Hypermedia，是驅(qū)動應(yīng)用狀態(tài)轉(zhuǎn)換的“引擎”。

再進一步想想，在RESTful架構(gòu)中，所有的狀態(tài)其實就組成了一顆樹(更準確地說是網(wǎng))：根節(jié)點就是網(wǎng)站的基地址。在你獲取一個節(jié)點中的資源的同時，服務(wù)器還會返回給你這個節(jié)點的邊：Hypermedia(超鏈接就是一種Hypermedia)。通過Hypermedia，你能夠知道相鄰節(jié)點的基本信息、地址。
結(jié)果就是：你能夠訪問到這顆樹的所有節(jié)點，而你所需要提前知道的只是“如何到達根節(jié)點”而已！

每個節(jié)點就是一個狀態(tài)。用戶可以在這個狀態(tài)網(wǎng)中不斷跳轉(zhuǎn)。
這個例子（知乎）和這個例子（stackoverflow）也是不錯的解釋。
wikipedia的解釋：a REST client should then be able to use server-provided links dynamically to discover all the available actions and resources it needs. As access proceeds, the server responds with text that includes hyperlinks to other actions that are currently available. There is no need for the client to be hard-coded with information regarding the structure or dynamics of the REST service.

這種架構(gòu)的優(yōu)勢非常明顯：前后端之間的耦合更加微弱。
隨著應(yīng)用功能的升級改變，“樹”的樣子會大大改變，但是只需要讓后端修改返回的資源內(nèi)容和Hypermedia，前端幾乎不用改動。功能的演化更加靈活了。

現(xiàn)在你應(yīng)該明白Representational State Transfer中的State Transfer(狀態(tài)傳輸)是什么意思了：在HATEOAS中，服務(wù)端將客戶端所處的狀態(tài)和可以達到的狀態(tài)傳輸給客戶端。

等一下，在前面的資源小節(jié)，我們不是說過傳輸?shù)氖琴Y源表示（representation）嗎？怎么這里又說傳輸?shù)氖菭顟B(tài)？

其實在REST架構(gòu)風格中，“傳輸狀態(tài)”和“傳輸資源表示”是同一個意思。客戶端所處的狀態(tài)，是由它接收到的資源表示來決定的。比如，客戶端接收到/user/csr/blogs資源，那么客戶端的狀態(tài)就變成/user/csr/blogs(顯示csr的文章列表)。
等一下，為什么客戶端會收到“/user/csr/blogs”資源？因為客戶端請求的就是“/user/csr/blogs”資源。
繼續(xù)追溯，為什么客戶端會請求這個資源？因為用戶點擊了“查看文章列表”的鏈接（這個鏈接其實就是一個Hypermedia）。
繼續(xù)追溯，為什么有一個“查看文章列表”的鏈接顯示給用戶點擊？因為HATEOAS：服務(wù)端在返回上一個狀態(tài)（資源）的時候，會返回所有相鄰狀態(tài)的Hypermedia，其中就包括“查看文章列表”這個Hypermedia。客戶端會展示所有相鄰狀態(tài)的Hypermedia供用戶選擇。

按照從前往后的順序梳理一遍：

客戶端請求根資源
=> 服務(wù)器返回根資源的表示，以及相鄰資源的Hypermedia
=> 客戶端進入“根資源”狀態(tài)（比如說，展示首頁）
=> 客戶端顯示所有相鄰狀態(tài)的Hypermedia供用戶選擇（比如，在首頁有一個導航欄，里面有幾個鏈接）
=> 用戶選擇了某個Hypermedia（比如，點擊了“查看文章列表”的鏈接）
=> 客戶端請求“文章列表”資源
=> 服務(wù)器返回“文章列表”資源的表示，以及相鄰資源的Hypermedia
=> 客戶端進入“文章列表”狀態(tài)
=> 客戶端顯示所有相鄰狀態(tài)的Hypermedia供用戶選擇（比如，在文章列表里，顯示所有文章的鏈接）
……

不難發(fā)現(xiàn)，客戶端接收到一個新的資源表示，就會跳轉(zhuǎn)到新的狀態(tài)，這個過程稱為狀態(tài)傳輸（服務(wù)器給客戶端傳輸新狀態(tài)）。因此狀態(tài)傳輸是通過傳輸資源表示來完成的。

Representational State Transfer的語法結(jié)構(gòu)是(Representational (State Transfer))，在這里我們用的是representation的形容詞形式，意思是在表示層上的狀態(tài)傳輸。這個詞的字面意思是通過傳輸資源表示來傳輸客戶端狀態(tài)。

REST的字面意思在網(wǎng)絡(luò)上有很多種理解，我參考了某位答主的兩個回答：https://stackoverflow.com/a/1... 和 https://stackoverflow.com/a/4... ，因為這位答主的回答最符合wikipedia的解釋："The term is intended to evoke an image of how a well-designed Web application behaves: it is a network of Web resources (a virtual state-machine) where the user progresses through the application by selecting links, such as /user/tom, and operations such as GET or DELETE (state transitions), resulting in the next resource (representing the next state of the application) being transferred to the user for their use."

至此，我們應(yīng)該能夠體會到REST已經(jīng)不僅僅是一種API風格了，它是一種軟件架構(gòu)風格(REST本身不是一種架構(gòu))。REST風格的軟件架構(gòu)具有很強的演化、拓展能力：

一致的URL和HTTP動詞使用：確保系統(tǒng)能夠接納多樣而又標準的客戶端，保證客戶端的演化能力。

無狀態(tài)：保證了系統(tǒng)的橫向拓展能力、服務(wù)端的演化能力。

HATEOAS：保證了應(yīng)用本身的演化能力(功能增加、改變)。

這3點是單單對演化拓展優(yōu)勢的說明，這個回答總結(jié)了REST的6個約束分別對應(yīng)的優(yōu)點。

Roy Fielding 提出REST的論文
Representational state transfer - wikipedia
What exactly is RESTful programming? - stackoverflow
Do sessions really violate RESTfulness? - stackoverflow
steps toward the glory of REST - Martin Fowler(軟件開發(fā)“教父”)

怎樣用通俗的語言解釋REST，以及RESTful？ - 知乎
REST風格的優(yōu)勢是什么？ - 知乎
RESTful API 設(shè)計指南
What does Representational State mean in REST? - stackoverflow
Clarifying REST
REST APIs must be hypertext-driven - Roy Fielding

REST tutorial 1
REST tutorial 2

用戶注冊、登陸、登出的RESTful API設(shè)計