REST
為什么會(huì)有REST呢？
Web服務(wù)已經(jīng)成為異構(gòu)系統(tǒng)之間的互聯(lián)于集成的主要手段，過(guò)去Web服務(wù)幾乎都是采用SOAP（Simple Object Access Protocol睹酌，簡(jiǎn)單對(duì)象訪問協(xié)議）來(lái)構(gòu)建的战授。REST風(fēng)格的軟件架構(gòu)模式出現(xiàn)后就快速取代了復(fù)雜而笨重的SOAP采盒，成為Web API的標(biāo)準(zhǔn)。
什么是REST呢局冰？
REST全稱Representational State Transfer表述性狀態(tài)轉(zhuǎn)移
REST于2000年被Roy Thomas Fielding博士提出，是基于HTTP灌危、URI康二、XML、JSON等標(biāo)準(zhǔn)和協(xié)議勇蝙，支持輕量級(jí)沫勿、跨平臺(tái)、跨語(yǔ)言的架構(gòu)設(shè)計(jì)味混，是Web服務(wù)的一種新的架構(gòu)風(fēng)格产雹。
Roy Thomas Fielding將REST定位為“分布式超媒體應(yīng)用（Distributed Hypermedia System）”的架構(gòu)風(fēng)格。
例如：在面向終端用戶的Web應(yīng)用中翁锡，應(yīng)用狀態(tài)表示W(wǎng)eb應(yīng)用中客戶端狀態(tài)蔓挖，簡(jiǎn)單理解可視為會(huì)話狀態(tài)。資源在瀏覽器中以超媒體的形式呈現(xiàn)馆衔，通過(guò)點(diǎn)擊超媒體中的超鏈接獲取其它相關(guān)的資源或?qū)Ξ?dāng)前資源進(jìn)行相關(guān)處理瘟判。另外，獲取的資源或針對(duì)資源處理的響應(yīng)同樣以超媒體的形式再次呈現(xiàn)在瀏覽器上角溃。因此拷获，超媒體成為了驅(qū)動(dòng)客戶端會(huì)話狀態(tài)轉(zhuǎn)換的引擎（Hypermedia as the engine of appliation state, HATEOAS）。
借助于超媒體這種特殊的資源呈現(xiàn)方式开镣，應(yīng)用狀態(tài)的轉(zhuǎn)換體現(xiàn)為瀏覽器中呈現(xiàn)資源的轉(zhuǎn)換刀诬。如果將超媒體進(jìn)一步抽象成一般意義上的資源呈現(xiàn)（Representation）方式咽扇，那么應(yīng)用狀態(tài)變成了“可被呈現(xiàn)的狀態(tài)（Representational State）”邪财。因此，應(yīng)用狀態(tài)之間的轉(zhuǎn)換就成了“可被呈現(xiàn)的狀態(tài)轉(zhuǎn)換（Representational State Transfer）”质欲，也就是REST树埠。
REST描述了一種架構(gòu)樣式的網(wǎng)絡(luò)系統(tǒng)，如Web應(yīng)用程序嘶伟。在目前主流的Web服務(wù)交互方案中怎憋，REST相比SOAP（Simple Object Access Protocol，簡(jiǎn)單對(duì)象訪問協(xié)議）和XML-RPC更加簡(jiǎn)單明了九昧，無(wú)論是對(duì)URL的處理還是對(duì)Payload的編碼绊袋，REST都傾向于使用更加簡(jiǎn)單輕量的設(shè)計(jì)和實(shí)現(xiàn)。
REST其實(shí)是對(duì)資源的表述性狀態(tài)轉(zhuǎn)移铸鹰，它并沒有明確的標(biāo)準(zhǔn)而更像是一種設(shè)計(jì)風(fēng)格癌别。
- 表述性（
Representational）是指客戶端請(qǐng)求一個(gè)資源，服務(wù)器拿到的這個(gè)資源蹋笼，就是表述展姐。 - 資源是
REST系統(tǒng)的核心概念躁垛，所有的設(shè)計(jì)都是以資源為中心的。 - 資源的地址在Web中就是
URL統(tǒng)一資源定位符
REST架構(gòu)原則
- 對(duì)網(wǎng)絡(luò)上所有資源都有一個(gè)資源標(biāo)識(shí)符
- 對(duì)資源的操作不會(huì)改變標(biāo)識(shí)符
- 同一資源有多種表現(xiàn)形式圾笨，如
XML教馆、JSON... - 所有操作都是無(wú)狀態(tài)的（
Stateless）
REST系統(tǒng)特征
- 客戶端與服務(wù)器（
Client-Server）
提供服務(wù)的服務(wù)器和使用服務(wù)的客戶端需要被隔離對(duì)待 - 無(wú)狀態(tài)（
Stateless）
來(lái)自客戶端的每個(gè)請(qǐng)求必須包含服務(wù)器處理該請(qǐng)求所需的所有信息，換句話說(shuō)擂达，服務(wù)器不能存儲(chǔ)來(lái)自某個(gè)客戶端某個(gè)請(qǐng)求中的信息土铺，并在該客戶端的其它請(qǐng)求中使用。 - 可緩存（
Cachable）
服務(wù)器必須讓客戶端知道請(qǐng)求是否可以被緩存 - 分層系統(tǒng)（
Layered System）
服務(wù)器和客戶端之間的通信必須被標(biāo)準(zhǔn)化谍婉，即允許服務(wù)器和客戶端之間的中間層可以代替服務(wù)器對(duì)客戶端的請(qǐng)求進(jìn)行回應(yīng)舒憾，而且這些客戶端來(lái)說(shuō)不需要特別支持。 - 統(tǒng)一接口（
Uniform Interface）
客戶端和服務(wù)器之間通信的方法必須時(shí)統(tǒng)一化的 - 支持按需代碼（
Code-On-Demand）
服務(wù)器可以提供一些代碼或腳本并在客戶端的運(yùn)行環(huán)境中執(zhí)行穗熬，這條準(zhǔn)則是唯一不必必須滿足的镀迂。
REST成熟度的層次
- 第一個(gè)層次
Level0的Web服務(wù)
使用HTTP作為傳輸方式，實(shí)際只是遠(yuǎn)程方法調(diào)用RPC的一種具體形式唤蔗，如SOAP和XML-RPC探遵。 - 第二個(gè)層次
Level1的Web服務(wù)
引入資源的概念，每個(gè)資源都有與之對(duì)應(yīng)的標(biāo)識(shí)符和表達(dá)妓柜。 - 第三個(gè)層次
Level2的Web服務(wù)
使用不同的HTTP方法來(lái)進(jìn)行不同的操作箱季，并使用HTTP狀態(tài)碼表示不同結(jié)果。 - 第四個(gè)層次
Level3的Web服務(wù)
使用HATEOAS棍掐，在資源的表達(dá)中包含了鏈接信息藏雏，客戶端可以根據(jù)鏈接來(lái)發(fā)現(xiàn)可以執(zhí)行的動(dòng)作。
簡(jiǎn)單來(lái)說(shuō)作煌，REST就是使用URL定位資源 + 使用HTTP動(dòng)詞（GET/POST/DELETE/HEAD/PUT）描述操作掘殴。
RESTful
RESTful是一種常見的REST應(yīng)用，是遵循REST風(fēng)格的Web服務(wù)粟誓，而REST風(fēng)格的Web本質(zhì)則是一種面向資源的架構(gòu)（Resource Oriented Architecture, ROA）奏寨。
如果一個(gè)架構(gòu)符合REST原則就稱為RESTful架構(gòu)，HTTP就是RESTful架構(gòu)風(fēng)格的一個(gè)典型應(yīng)用鹰服。
資源
表述性狀態(tài)轉(zhuǎn)移中的表述其實(shí)指的是資源（Resources）病瞳，任何事物只要有被引用到的必要，它就是一個(gè)資源悲酷。資源可以是實(shí)體也可以是一種抽象概念套菜，要讓資源可以被識(shí)別，就需要具有唯一標(biāo)識(shí)设易。
資源是一個(gè)很寬泛的概念逗柴，任何寄宿于Web可供操縱的“事物”都可視為資源，資源可以體現(xiàn)為經(jīng)過(guò)持久化處理保存到磁盤上的某個(gè)文件或是數(shù)據(jù)庫(kù)中某個(gè)表的記錄亡嫌，也可以是Web應(yīng)用接收請(qǐng)求后采用某算法計(jì)算所得的結(jié)果嚎于。簡(jiǎn)單來(lái)說(shuō)掘而，資源可以體現(xiàn)為一個(gè)具體的物理對(duì)象，也可以是一個(gè)抽象的流程于购。
資源是一種信息實(shí)體袍睡，可以有多種外在表現(xiàn)形式，資源具體呈現(xiàn)出來(lái)的形式稱為表現(xiàn)層（Representation）肋僧。例如：文本可通過(guò)txt格式表現(xiàn)也可用HTML表現(xiàn)等斑胜。
統(tǒng)一資源標(biāo)識(shí)符
一個(gè)資源必須具有一個(gè)或多個(gè)標(biāo)識(shí)，在設(shè)計(jì)Web應(yīng)用的API時(shí)嫌吠，由于Web系統(tǒng)中資源的唯一標(biāo)識(shí)是URI（Uniform Resource Identifier止潘，統(tǒng)一資源標(biāo)識(shí)符），所以自然采用URI作為資源的標(biāo)識(shí)辫诅。
schema://host[:port]/path[?query-string][#anchor]
schema 指定底層所使用的協(xié)議凭戴，如HTTP、HTTPS炕矮、FTP...
host 服務(wù)器的IP地址或域名
port 服務(wù)器端口么夫，默認(rèn)80
path 訪問資源的路徑
query-string 發(fā)送給HTTP服務(wù)器的數(shù)據(jù)
anchor 錨點(diǎn)
URI既可以看作是資源的地址，也可以看作是資源的名稱肤视。如果某些信息沒有使用URI來(lái)表示档痪，那它就不能算是一個(gè)資源，只能算是資源的信息邢滑。
URI的設(shè)計(jì)遵循著可尋址性原則腐螟，具有自描述性，在形式上需要給人直覺上的關(guān)聯(lián)困后。因?yàn)榫哂锌勺x性的URI更容易被使用乐纸，使用者一看就知道被標(biāo)識(shí)的是何種資源。
除了必要的標(biāo)志性和可選的可讀性之外操灿，標(biāo)識(shí)資源的URI應(yīng)該具有“可尋址性（Addressability）”锯仪，也就是說(shuō)泵督，URI不僅僅指明了被標(biāo)識(shí)資源所在的位置趾盐，通過(guò)這個(gè)URI還可以直接獲取目標(biāo)資源。
URI具有URL和URN兩種主要的表現(xiàn)形式小腊，由于URL具有可尋址性救鲤，所以推薦采用URL作為資源的標(biāo)識(shí)。
URI除了可以標(biāo)識(shí)某個(gè)獨(dú)立的資源外秩冈，還可以標(biāo)識(shí)一組資源的集合或者是資源的容器本缠。當(dāng)然，一組同類資源的集合或存放一組同類資源的容器本身也可以視為另一種類型的復(fù)合型（Composite）資源入问。所以丹锹，“URI總是標(biāo)識(shí)某個(gè)資源”的說(shuō)法是沒錯(cuò)的稀颁。
REST是面向資源的，而資源是通過(guò)URI進(jìn)行暴露楣黍，URI的設(shè)計(jì)只負(fù)責(zé)把資源通過(guò)合理的方式暴露出來(lái)就可以了匾灶。對(duì)資源的操作于它無(wú)關(guān)，操作是通過(guò)HTTP動(dòng)詞來(lái)體現(xiàn)的租漂。所以REST通過(guò)URI暴露資源時(shí)阶女，會(huì)強(qiáng)調(diào)不要在URI中出現(xiàn)動(dòng)詞。
URI只代表資源的實(shí)體哩治，并不代表它的形式秃踩。嚴(yán)格來(lái)說(shuō)，網(wǎng)址后的文件后綴是不必要的业筏，因?yàn)槲募缶Y標(biāo)識(shí)的是格式憔杨，是屬于表現(xiàn)層的范疇。URI應(yīng)該只代表資源的位置蒜胖，它的具體表現(xiàn)形式芍秆，應(yīng)該在HTTP請(qǐng)求的頭信息中使用Accept和Content-Type字段指定，因?yàn)檫@兩個(gè)字段才是對(duì)表現(xiàn)成的描述翠勉。
例如：github站點(diǎn)的URI的設(shè)計(jì)https://github.com/git/git/commit/e3af72cdafab5993d18fae056f87e1d675913d08
URI設(shè)計(jì)技巧
- 使用下劃線
_或中劃線-分隔單詞可以讓URI可讀性更好
例如：http://www.oschina.net/news/38119/oschina-translate-reward-plan
- 使用斜線
/表示資源的層級(jí)關(guān)系
例如：/git/git/commit/e3af72cdafab5993d18fae056f87e1d675913d08表示一個(gè)多級(jí)的資源妖啥，表示git用戶的git項(xiàng)目的某次提交
例如：/orders/2019/10表示2019年10月的訂單記錄
- 使用問號(hào)
?用于過(guò)濾資源
URI中的?并非只能用于傳遞參數(shù)，?可以用于對(duì)資源的過(guò)濾对碌。
例如：/git/git/pulls?state=closed表示git項(xiàng)目中已經(jīng)關(guān)閉的推入請(qǐng)求
- 使用逗號(hào)
,或分號(hào);用來(lái)表示同級(jí)資源的關(guān)系
為了表示同級(jí)資源的關(guān)系荆虱，可使用逗號(hào),或分號(hào);進(jìn)行分隔
例如：/git/git /block-sha1/sha1.h/compare/e3af72cdafab5993d18fae056f87e1d675913d08;bd63e61bdf38e872d5215c07b264dcc16e4febca 比較git中某個(gè)文件兩次提交記錄之間的差，現(xiàn)在GitHub使用...三個(gè)點(diǎn)號(hào)來(lái)比較兩次提交記錄之間的差異朽们。
統(tǒng)一資源接口
REST是指一組架構(gòu)約束條件和原則怀读，滿足這些約束條件和原則的應(yīng)用程序或設(shè)計(jì)就是RESTful。
RESTful架構(gòu)的核心規(guī)范與約束是統(tǒng)一接口骑脱，又分為四個(gè)子約束：
- 每個(gè)資源都擁有一個(gè)資源標(biāo)識(shí)菜枷，每個(gè)資源的資源標(biāo)識(shí)可以用來(lái)唯一的標(biāo)明該資源。
- 消息的自描述性
- 資源的自描述性
- 使用超媒體作為應(yīng)用狀態(tài)引擎
Web應(yīng)用程序中最重要的RESTful原則是：客戶端和服務(wù)器之間的交互在請(qǐng)求之間是無(wú)狀態(tài)的叁丧。
從客戶端到服務(wù)器的每個(gè)請(qǐng)求都必須包含理解請(qǐng)求所必須的信息啤誊。如果服務(wù)器在請(qǐng)求之間的任何時(shí)間點(diǎn)重啟，客戶端將不會(huì)得到通知拥娄。另外蚊锹，無(wú)狀態(tài)請(qǐng)求可以由任何可用服務(wù)器應(yīng)答，這一點(diǎn)十分適合云計(jì)算之類的環(huán)境稚瘾，客戶端可以緩存數(shù)據(jù)以改進(jìn)性能牡昆。
在服務(wù)器上應(yīng)用程序狀態(tài)和功能可以劃分為各種資源，資源是一個(gè)有趣的概念實(shí)體摊欠，它向客戶端公開丢烘。每個(gè)資源都使用URI得到一個(gè)唯一的地址柱宦。所有資源都共享統(tǒng)一的接口，以便在客戶端和服務(wù)器之間傳遞狀態(tài)播瞳。
RESTful架構(gòu)應(yīng)該遵循統(tǒng)一接口原則捷沸，統(tǒng)一接口包括一組受限且預(yù)定義的操作，無(wú)論是什么樣的資源狐史，都是通過(guò)使用相同的接口進(jìn)行資源的訪問痒给。接口使用標(biāo)準(zhǔn)的HTTP方法如GET、POST骏全、PUT等苍柏，并遵循這些方法的語(yǔ)義。
如果按照HTTP方法的語(yǔ)義來(lái)暴露資源姜贡，那么接口將會(huì)擁有安全性和冪等性的特性试吁。例如：GET和HEAD請(qǐng)求都是安全的，無(wú)論請(qǐng)求多少次楼咳，都不會(huì)改變服務(wù)器的狀態(tài)熄捍。而GET、HEAD母怜、PUT余耽、DELETE請(qǐng)求又都是冪等的，無(wú)論對(duì)資源操作多少次苹熏，結(jié)構(gòu)總是一樣的碟贾，后續(xù)的請(qǐng)求并不會(huì)產(chǎn)生比第一次更多的影響。
關(guān)于HTTP請(qǐng)求方法具有兩個(gè)基本的特性轨域，即“安全性”和“冪等性”袱耽。
- 冪等性（Idempotent）表示對(duì)同一
REST接口的多次訪問得到的資源狀態(tài)都是相同的 - 安全性表示對(duì)
REST接口訪問將不會(huì)使服務(wù)器資源的狀態(tài)發(fā)生改變
狀態(tài)轉(zhuǎn)化
實(shí)際上狀態(tài)分為應(yīng)用狀態(tài)和資源狀態(tài)，客戶端負(fù)責(zé)維護(hù)應(yīng)用狀態(tài)干发，服務(wù)器維護(hù)資源狀態(tài)朱巨。客戶端與服務(wù)器的交互必須是無(wú)狀態(tài)的枉长，在每次請(qǐng)求中包含處理該請(qǐng)求所需的一切信息冀续。服務(wù)器不需要在請(qǐng)求之間保留應(yīng)用狀態(tài)，只有在接收到實(shí)際請(qǐng)求時(shí)服務(wù)器才會(huì)關(guān)注應(yīng)用狀態(tài)搀暑。這種無(wú)狀態(tài)的通信原則沥阳，使得服務(wù)器和中介能夠立即獨(dú)立的請(qǐng)求和響應(yīng)跨琳。在多次請(qǐng)求中自点，同一客戶端也不再需要依賴于同一臺(tái)服務(wù)器，方便實(shí)現(xiàn)高可擴(kuò)展和高可用性的服務(wù)器脉让。簡(jiǎn)單來(lái)說(shuō)桂敛，這種無(wú)狀態(tài)的通信原則并不是說(shuō)客戶端應(yīng)用不能有狀態(tài)功炮，而是指服務(wù)器不應(yīng)該保存客戶端的狀態(tài)。
會(huì)話狀態(tài)不是作為資源狀態(tài)保存在服務(wù)器的术唬，而是被客戶端作為應(yīng)用狀態(tài)進(jìn)行跟蹤的薪伏。客戶端應(yīng)用狀態(tài)在服務(wù)器提供的超媒體的指引下發(fā)生變遷粗仓。服務(wù)器通過(guò)超媒體高速客戶端當(dāng)前狀態(tài)有那些后續(xù)狀態(tài)可以進(jìn)入嫁怀。
客戶端與服務(wù)器的一個(gè)互動(dòng)過(guò)程中勢(shì)必涉及到數(shù)據(jù)和狀態(tài)的變化，由于HTTP本身是無(wú)狀態(tài)的借浊，這意味著所有的狀態(tài)都保存在服務(wù)器上塘淑。因此，如果客戶端想要操作服務(wù)器蚂斤，必須通過(guò)某種手段讓服務(wù)器發(fā)生“狀態(tài)轉(zhuǎn)化（State Transfer）”存捺。而這種轉(zhuǎn)化是建立在表現(xiàn)層之上的，所以就是“表現(xiàn)層狀態(tài)轉(zhuǎn)化”曙蒸。
客戶端能夠用到的手段只能是HTTP協(xié)議捌治，具體來(lái)說(shuō)是HTTP協(xié)議中四個(gè)表示操作方式的動(dòng)詞：GET、POST纽窟、PUT肖油、DELETE，它們分別對(duì)應(yīng)四種基本操作：
-
GET用來(lái)獲取資源 -
POST用于新建資源臂港，也可以用于更新資源构韵。 -
PUT用于更新資源 -
DELETE用于刪除資源
RESTful對(duì)于資源的操作主要包括增刪改查CURD，由HTTP動(dòng)詞或謂詞表示趋艘。
-
POST：用于在服務(wù)器中新建一個(gè)資源疲恢，對(duì)應(yīng)資源操作是增加INSERT，非冪等且不安全瓷胧。 -
DELETE：用于從服務(wù)器刪除資源显拳，對(duì)應(yīng)資源操作是刪除DELETE，冪等且不安全搓萧。 -
PUT：用于在服務(wù)器中更新資源杂数，客戶端提供改變后的完整資源，對(duì)應(yīng)資源操作是修改UPDATE瘸洛，冪等且不安全揍移。 -
GET：用于從服務(wù)器中取出資源，對(duì)應(yīng)資源操作是查詢SELECT反肋，冪等且安全那伐。
資源的表述
客戶端通過(guò)HTTP方法可獲取資源，準(zhǔn)確來(lái)說(shuō)客戶端獲取的只是資源的表述而已。資源在外界的具體呈現(xiàn)方式可以有多種表現(xiàn)形式罕邀，在客戶端和服務(wù)器之間傳輸?shù)囊彩琴Y源的表述畅形，而不是資源本身。例如：文本資源可以采用HTML诉探、XML日熬、JSON等格式，圖片可以使用PNG肾胯、JPG等格式展現(xiàn)竖席。
資源的表述包括數(shù)據(jù)和描述數(shù)據(jù)的元數(shù)據(jù)，例如：HTTP頭信息的Content-Type字段就是這樣的一個(gè)元數(shù)據(jù)屬性敬肚。
問題是客戶端如何知道服務(wù)器提供那種表述形式呢怕敬？答案是通過(guò)HTTP內(nèi)容協(xié)商，客戶端可以通過(guò)Accept頭請(qǐng)求一種特定格式的表述帘皿，服務(wù)器則通過(guò)Content-Type告知客戶端資源的表述形式东跪。
例如：請(qǐng)求組織資源的JSON格式的表述形式
# HTTP請(qǐng)求頭
GET http://api.github.com/orgs/github HTTP/1.1
Accept: application/json
# HTTP響應(yīng)頭
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
最佳實(shí)踐
在URI中帶上版本號(hào)
例如http://api.example.com/1.0/foo，如果把版本號(hào)理解成資源的不同表述形式的話鹰溜，那就應(yīng)該只是用一個(gè)URL虽填，并通過(guò)Accept字段來(lái)區(qū)分，以Github為例其格式為application/vnd.github[.version].param[+json]曹动。
Accept: vnd.example-com.foo+json; version=1.0
資源的URL設(shè)計(jì)斋日，可通過(guò)URL來(lái)表示資源，首先資源可分為主資源和子資源墓陈，主資源表示一類獨(dú)立的資源恶守，索引主資源應(yīng)該直接放到相對(duì)路徑下。一個(gè)子資源可能是一個(gè)集合也可能是一個(gè)單一的子資源贡必。
例如：表示主資源的實(shí)例/goods/1兔港，表示子資源的集合/goods/1/pictures。
RESTful的核心思想是客戶端發(fā)出的數(shù)據(jù)操作指令都是“動(dòng)詞+賓語(yǔ)”的結(jié)構(gòu)
比如：GET /users這個(gè)命令仔拟，其中GET是動(dòng)詞衫樊，/users是賓語(yǔ)。
動(dòng)詞通常就是五種HTTP方法對(duì)應(yīng)著CURD操作利花，根據(jù)HTTP規(guī)范動(dòng)詞一律大寫科侈。有些客戶端只能使用GET和POST兩種方法，服務(wù)器必須接收POST模擬其它三個(gè)方法PUT炒事、PATCH臀栈、DELETE，這時(shí)客戶端發(fā)出的HTTP請(qǐng)求中就需要附加上X-HTTP-Method-Override屬性挠乳，它會(huì)覆蓋掉POST方法权薯，用以告知服務(wù)器應(yīng)該使用哪一個(gè)動(dòng)詞姑躲。
例如：下列請(qǐng)求的方法是PUT而非POST
POST /api/users/1 HTTP/1.1
X-HTTP-Method-Override: PUT
賓語(yǔ)必須是名詞
賓語(yǔ)是API的URL，是HTTP動(dòng)詞作用的對(duì)象崭闲，它應(yīng)該是名詞肋联，不能是動(dòng)詞威蕉。既然URL是名詞刁俭，那么應(yīng)該使用復(fù)數(shù)還是單數(shù)呢？這個(gè)沒有統(tǒng)一的規(guī)定韧涨，常見的操作是讀取一個(gè)集合時(shí)使用復(fù)數(shù)牍戚。為了統(tǒng)一起見建議都使用復(fù)數(shù)的URL。
避免多級(jí)URL
當(dāng)資源需要多級(jí)分類時(shí)就會(huì)很容易出現(xiàn)多級(jí)URL虑粥，比如獲取某個(gè)用戶的某類數(shù)據(jù)：GET /users/10/categories/2如孝，這種URL不利于擴(kuò)展而且語(yǔ)義也不明確，往往需要想一下才能明白含義娩贷。更好的做法時(shí)除了第一級(jí)其它級(jí)別都使用查詢字符串表示第晰，比如GET /users/10?categories=2。
比如要查詢某個(gè)狀態(tài)的數(shù)據(jù)時(shí)會(huì)設(shè)計(jì)成這樣GET /users/locked彬祖，但使用查詢字符串的寫法明顯會(huì)更好 GET /users?locked=true茁瘦。
REST很好地利用了HTTP本身的一些特性，如HTTP動(dòng)詞储笑、HTTP狀態(tài)碼甜熔、HTTP報(bào)頭等。REST API是基于HTTP的突倍，所以設(shè)計(jì)的API應(yīng)該去使用HTTP的一些標(biāo)準(zhǔn)腔稀，這樣所有的HTTP客戶端才能夠直接理解你的API并有利于緩存等。RSET實(shí)際上也非常調(diào)用應(yīng)該利用好HTTP本來(lái)就有的特性羽历，而不是只把HTTP當(dāng)成一個(gè)傳輸層協(xié)議這樣簡(jiǎn)單焊虏。
