摘要：實(shí)現(xiàn)與它們所提供的服務(wù)是解耦的，這促進(jìn)了獨(dú)立的可進(jìn)化性。正確的情況返回與響應(yīng)碼，在錯(cuò)誤的情況下他們通常返回或。示例用于刪除由標(biāo)識(shí)的資源。成功刪除返回及響應(yīng)正文或沒有正文響應(yīng)。客戶不存在，不合法資源命名一切在工藝軟件開發(fā)的命名是成功的關(guān)鍵。

REST 即表述性狀態(tài)傳遞（英文：Representational State Transfer，簡稱REST）是Roy Fielding博士在2000年他的博士論文中提出來的一種軟件架構(gòu)風(fēng)格（http://www.ics.uci.edu/~field...）。它是一種針對(duì)網(wǎng)絡(luò)應(yīng)用的設(shè)計(jì)和開發(fā)方式，可以降低開發(fā)的復(fù)雜性，提高系統(tǒng)的可伸縮性。

統(tǒng)一接口（Uniform Interface）

無狀態(tài)（Stateless）

緩存（Cacheable）

客戶-服務(wù)器（Client-Server）

分層系統(tǒng)（Layered System）

按需代碼（Code on Demand）

使REST 架構(gòu)風(fēng)格區(qū)別于其他基于網(wǎng)絡(luò)的架構(gòu)風(fēng)格的核心特征是，它強(qiáng)調(diào)組件之間要有一個(gè)統(tǒng)一的接口。通過在組件接口上應(yīng)用通用性的軟件工程原則，整體的系統(tǒng)架構(gòu)得到了簡化，交互的可見性也得到了改善。實(shí)現(xiàn)與它們所提供的服務(wù)是解耦的，這促進(jìn)了獨(dú)立的可進(jìn)化性。然而，付出的代價(jià)是，統(tǒng)一接口降低了效率，因?yàn)樾畔⒍际褂脴?biāo)準(zhǔn)化的形式來轉(zhuǎn)移，而不能使用特定于應(yīng)用的需求的形式。REST 接口被設(shè)計(jì)為可以高效地轉(zhuǎn)移大粒度的超媒體數(shù)據(jù)，并針對(duì)Web的常見情況做了優(yōu)化，但是這也導(dǎo)致了該接口對(duì)于其他形式的架構(gòu)交互并不是最優(yōu)的。

通信必須在本質(zhì)上是無狀態(tài)的，因此從客戶到服務(wù)器的每個(gè)請(qǐng)求都必須包含理解該請(qǐng)求所必需的所有信息，不能利用任何存儲(chǔ)在服務(wù)器上的上下文，會(huì)話狀態(tài)因此要全部保存在客戶端。

為了改善網(wǎng)絡(luò)的效率。緩存約束要求一個(gè)請(qǐng)求的響應(yīng)中的數(shù)據(jù)被隱式地或顯式地標(biāo)記為可緩存的或不可緩存的。如果響應(yīng)是可緩存的，那么客戶端緩存就可以為以后的相同請(qǐng)求重用這個(gè)響應(yīng)的數(shù)據(jù)。

通過分離用戶接口和數(shù)據(jù)存儲(chǔ)這兩個(gè)關(guān)注點(diǎn)，我們改善了用戶接口跨多個(gè)平臺(tái)的可移植性；同時(shí)通過簡化服務(wù)器組件，改善了系統(tǒng)的可伸縮性。然而，對(duì)于 Web來說，最重要的是這種關(guān)注點(diǎn)的分離允許組件獨(dú)立地進(jìn)化，從而支持多個(gè)組織領(lǐng)域的Internet規(guī)模的需求。

分層系統(tǒng)風(fēng)格通過限制組件的行為（即，每個(gè)組件只能“看到”與其交互的緊鄰層），將架構(gòu)分解為若干等級(jí)的層。通過將組件對(duì)系統(tǒng)的知識(shí)限制在單一層內(nèi)，為整個(gè)系統(tǒng)的復(fù)雜性設(shè)置了邊界，并且提高了底層獨(dú)立性。我們能夠使用層來封裝遺留的服務(wù)，使新的服務(wù)免受遺留客戶端的影響，通過將不常用的功能轉(zhuǎn)移到一個(gè)共享的中間組件中，從而簡化組件的實(shí)現(xiàn)。中間組件還能夠通過支持跨多個(gè)網(wǎng)絡(luò)和處理器的負(fù)載均衡，來改善系統(tǒng)的可伸縮性。

通過減少必須被預(yù)先實(shí)現(xiàn)的功能的數(shù)目，簡化了客戶端的開發(fā)。允許在部署之后下載功能代碼也改善了系統(tǒng)的可擴(kuò)展性。然而，這也降低了可見性，因此它只是 REST 的一個(gè)可選的約束。

HTTP GET 用于檢索（讀取）資源。正確的情況返回JSON與200 HTTP響應(yīng)碼，在錯(cuò)誤的情況下他們通常返回404(NOT FOUND)或400(BAD REQUEST)。

示例
GET http://www.example.com/custom...
GET http://www.example.com/custom...
GET http://www.example.com/bucket...

通過GET它應(yīng)該永遠(yuǎn)不會(huì)修改服務(wù)器上的任何資源。

HTTP POST 通常用于創(chuàng)建資源。正確的情況返回201 HTTP響應(yīng)碼及Location header（資源 URI）。

示例
POST http://www.example.com/customers
POST http://www.example.com/custom...

HTTP PUT 通常用于更新資源。將請(qǐng)求正文內(nèi)容替換已知資源的原始數(shù)據(jù)。

示例
PUT http://www.example.com/custom...
PUT http://www.example.com/custom...

HTTP DELETE 用于刪除由URI標(biāo)識(shí)的資源。成功刪除返回200 HTTP及響應(yīng)正文或沒有正文響應(yīng)204 HTTP(NO CONTENT)。

示例
DELETE http://www.example.com/custom...
DELETE http://www.example.com/custom...
DELETE http://www.example.com/bucket...

下表是 URI 結(jié)合 HTTP METHOD 建議的返回值

一切在工藝軟件開發(fā)的命名是成功的關(guān)鍵。

除了適當(dāng)?shù)膽?yīng)用 HTTP Verb(Method)，資源命名可以說是最受爭議和最重要的概念。當(dāng)資源被命名好時(shí)，API 是直觀和易于使用的。做得太差，同樣的 API 能感覺太表面化和難以使用和理解。下面是一些提示，讓你去當(dāng)創(chuàng)建資源 URI 為您新的 API。

資源 URI 應(yīng)使用名詞而不是動(dòng)詞命名。一個(gè) RESTful URI 應(yīng)該指一種資源，而不是采取行動(dòng)。名詞具有屬性而動(dòng)詞沒有。

服務(wù)套件中每個(gè)資源至少有一個(gè) URI 標(biāo)識(shí)它。URI 應(yīng)遵循一種可預(yù)見，分層結(jié)構(gòu)，以增加可理解性，從而提高可用性。

在一個(gè)訂單系統(tǒng)與客戶、訂單、行項(xiàng)目的資源設(shè)計(jì)：

創(chuàng)建一個(gè)新的客戶
POST http://www.example.com/customers

讀取客戶 ID 為 33245
GET http://www.example.com/custom...
相同的 URI 將用于更新(PUT)與刪除(DELETE)客戶

這里為產(chǎn)品設(shè)計(jì)的 URI:
POST http://www.example.com/products
創(chuàng)建一個(gè)新的產(chǎn)品

GET|PUT|DELETE http://www.example.com/produc...
讀取、更新、刪除 ID 為 66432 的產(chǎn)品為

現(xiàn)在變得很有趣，我們?nèi)绾螢榭蛻魟?chuàng)建新的訂單？
一種選擇是
POST http://www.example.com/orders
毫無疑問它是可以工作的，但它卻在客戶的上下文之外
下面的 URI 更清晰
POST http://www.example.com/custom...
現(xiàn)在我們知道這個(gè)訂單是為客戶 33245 創(chuàng)建的
獲取 33245 客戶訂單使用如下 URI
GET http://www.example.com/custom...
現(xiàn)在，我們繼續(xù)來看分層的 URI 設(shè)計(jì)。如下：
POST http://www.example.com/custom...
這會(huì)將行項(xiàng)目添加到訂單 #8769(這是客戶 #33245)，獲取該 URI 資源會(huì)返回訂單下所有的行項(xiàng)目，如果行項(xiàng)目毫無意義或者在客戶的上下文以外的地方能感覺到我們會(huì)提供這樣一個(gè) URI
POST www.example.com/orders/8769/lineitems

看看一些廣泛使用的 API 來得到資源命名竅門和利用你的隊(duì)友來完善您的 API 資源。
Twitter: https://dev.twitter.com/docs/api

Facebook: http://developers.facebook.co...

LinkedIn: https://developer.linkedin.co...

GitHub: https://developer.github.com/v3/

示例
{
   "url":"https://api.github.com/gists/20c98223d9b59e1d48e5",
   "id":"1",
   "description":"description of gist",
   "public":true,
   "user":{
       "login":"octocat",
       "id":1,
       "avatar_url":"https://github.com/images/error/octocat_happy.gif",
       "gravatar_id":"somehexcode",
       "url":"https://api.github.com/users/octocat"
   },
   "comments":0,
   "comments_url":"https://api.github.com/gists/19d18b30e8af75090307/comments/",
   "html_url":"https://gist.github.com/1",
   "git_pull_url":"git://gist.github.com/1.git",
   "git_push_url":"[email protected]:1.git",
   "created_at":"2010-04-14T02:15:15Z"
}

total_count 總記錄數(shù)

items 數(shù)據(jù)項(xiàng)

示例
{
   "total_count":40,
   "items":[
       {
           "id":3081286,
           "name":"Tetris",
           "full_name":"dtrupenn/Tetris",
           "owner":{
               "login":"dtrupenn",
               "id":872147,
               "type":"User"
           },
           "private":false,
           "html_url":"https://github.com/dtrupenn/Tetris",
           "description":"A C implementation of Tetris using Pennsim through LC4",
           "fork":false,
           "url":"https://api.github.com/repos/dtrupenn/Tetris",
           "created_at":"2012-01-01T00:31:50Z",
           "updated_at":"2013-01-05T17:58:47Z",
           "pushed_at":"2012-01-01T00:37:02Z"
       }
   ]
}

code 錯(cuò)誤碼

message 錯(cuò)誤信息

示例
{
   "code": 12345,
   "message": "錯(cuò)誤描述"
}

http://www.restapitutorial.com/
https://www.oschina.net/trans...