REST参考手册
總說(shuō)接口定義要遵守 RESTful，那么什么是REST呢，今天跟小編一起來(lái)了解一下這個(gè)規(guī)范吧~！
原文作者簡(jiǎn)介：
BRIAN SLETTEN是一個(gè)關(guān)注前沿技術(shù)的軟件工程師，現(xiàn)居于加州奧本。他的職業(yè)生涯橫跨了各個(gè)行業(yè)，包括零售、銀行、網(wǎng)絡(luò)游戲、國(guó)防、金融、酒店和醫(yī)療保健。他擁有威廉瑪麗學(xué)院的計(jì)算機(jī)科學(xué)學(xué)士學(xué)位。BRIAN SLETTEN致力于Web架構(gòu)、資源計(jì)算、社交網(wǎng)絡(luò)、語(yǔ)義網(wǎng)、數(shù)據(jù)科學(xué)、三維圖形、可視化、可伸縮系統(tǒng)、安全咨詢等第二十世紀(jì)末和第二十一世紀(jì)早期的技術(shù)。
引言
表述性狀態(tài)傳遞架構(gòu)風(fēng)格(Representational State Transfer)不是一項(xiàng)可購(gòu)的技術(shù)，或者是一個(gè)在軟件開(kāi)發(fā)項(xiàng)目中可以添加的庫(kù)。它是一種將信息提升為我們構(gòu)建的架構(gòu)的第一類元素的世界觀。 ?
我們用來(lái)描述“REST”系統(tǒng)的一些概念和術(shù)語(yǔ)參照了Roy Fielding博士的論文《基于網(wǎng)絡(luò)的軟件體系結(jié)構(gòu)的架構(gòu)風(fēng)格與設(shè)計(jì)》(http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm)。盡管這是一篇學(xué)術(shù)論文，用詞十分正式，但是它仍然保留了通俗易懂的特點(diǎn)，為實(shí)踐提供了許多依據(jù)。
這些概念在我們稱之為Web的實(shí)現(xiàn)中得到了很好的證明。倡導(dǎo)RESTful風(fēng)格在本質(zhì)上來(lái)說(shuō)，就是鼓勵(lì)組織在內(nèi)部采用對(duì)外相同的原則。
基本概念
REST服務(wù)基于統(tǒng)一資源定位器（URL）。它能夠?qū)⒅付ㄙY源與接受或返回的資源分開(kāi)。URL方案在 RFC1738 (https://tools.ietf.org/html/rfc1738)中被定義。
對(duì)于某虛構(gòu)的圖書館，它可能擁有一個(gè)如下所示的RESTful風(fēng)格的API：??
http://fakelibrary.org/library
因此，被暴露的并不一定是某種服務(wù)，而是一種對(duì)用戶來(lái)說(shuō)有價(jià)值的信息資源。實(shí)際上，URL用作資源的句柄，可以對(duì)資源進(jìn)行請(qǐng)求、更新或刪除。 ?
首先我們要發(fā)布和這個(gè)虛擬圖書館進(jìn)行RESTful風(fēng)格交互的方法。RESTful的返回類型可以是XML,JSON或者是某種其他的超媒體格式，比如Atom或者用戶自定義的MIME類型。一般來(lái)說(shuō)，我們要盡可能地復(fù)用現(xiàn)存的格式。但是，使用合理自定義的媒介的趨勢(shì)正在不斷增長(zhǎng)。 ?
用戶可以使用一個(gè)超文本傳輸協(xié)議(HTTP)的GET方法來(lái)請(qǐng)求一個(gè)資源。比如說(shuō)，在瀏覽器中輸入一個(gè)URL并點(diǎn)擊返回，選擇書簽，或者點(diǎn)擊一個(gè)錨引用鏈接。 ?
我們可以使用各種用戶端的API或者工具來(lái)與RESTful式的API進(jìn)行交互。如果使用命令行的curl工具，我們可以輸入： ?
$ curl http://fakelibrary.org/library
在命令行上，返回的結(jié)果的形式是默認(rèn)的。然而，我們并不想要這個(gè)形式的信息。所幸利用HTTP的機(jī)制，我們可以以不同的形式請(qǐng)求信息，可以在請(qǐng)求中指定一個(gè)“Accept”頭，如果服務(wù)器支持該請(qǐng)求，那么服務(wù)器就會(huì)將它返回到客戶端。根據(jù)下述格式再次使用curl： ?
$ curl –H "Accept:application/json" http://fakelibrary.org/library由于資源名與表單的分離，這種不同形式的信息請(qǐng)求方式是可行的。在REST中“R”指代的是“表示(representation)”而不是“資源(resource)”。在構(gòu)建系統(tǒng)的時(shí)候要牢記這一點(diǎn)，我們要允許客戶以他們想要的形式請(qǐng)求信息。
?
我們的虛擬圖書館中可能包含的URL：
http://fakelibrary.org/library - 有關(guān)圖書館的大致信息，以及查找特定書籍、DVD等的鏈接的基準(zhǔn)。
http://fakelibrary.org/book - 圖書的“信息空間”。從概念上講，它是所有可能的圖書的占位符。顯然，如果它是一個(gè)確定的值，我們就不能返回所有的書籍，但它可能會(huì)返回通過(guò)類別、關(guān)鍵字搜索等方式發(fā)現(xiàn)的圖書。
http://fakelibrary.org/book/category/1234 - 在書籍的信息空間里，我們可以想象以特定的類別（例如小說(shuō)、兒童書籍、園藝等）來(lái)瀏覽它們。
http://fakelibrary.org/book/isbn/978-0596801687 - 指代某一個(gè)特定的書籍。它應(yīng)該包括關(guān)于標(biāo)題、作者、出版者、藏書量、余量等信息。
上述提到的URL對(duì)于用戶來(lái)說(shuō)可能是只讀的，但是圖書館員可能會(huì)對(duì)這些資源進(jìn)行操作。
舉例來(lái)說(shuō)，我們可以向圖書的信息空間POST一個(gè)XML，來(lái)指代添加一本新的書籍。使用curl：
$ curl –u username:password -d @book.xml -H ? "Content-type: text/xml" http://fakelibrary.org/book此時(shí)，服務(wù)器可能會(huì)驗(yàn)證結(jié)果，創(chuàng)建與本書相關(guān)聯(lián)的數(shù)據(jù)記錄，并返回“成功創(chuàng)建新資源”的201響應(yīng)代碼。我們可以在響應(yīng)頭中找到新資源的URL。
每一個(gè)RESTful請(qǐng)求都包含了足夠的狀態(tài)來(lái)回應(yīng)請(qǐng)求。這滿足了服務(wù)器上的可見(jiàn)性與無(wú)狀態(tài)性，實(shí)現(xiàn)了系統(tǒng)的收縮性，并確定了正在執(zhí)行的請(qǐng)求。這有助于實(shí)現(xiàn)結(jié)果的緩存。在結(jié)果集中，服務(wù)器的地址和請(qǐng)求的狀態(tài)組合在一起形成一個(gè)計(jì)算散列鍵(hash key)：
http://fakelibrary.org + /book/isbn/978-0596801687
由于GET請(qǐng)求的特性，它允許客戶端在必要情況下做出非常具體的請(qǐng)求。用戶可以在本地緩存結(jié)果，服務(wù)器可以緩存在遠(yuǎn)程。另外，一些中間的體系結(jié)構(gòu)也可以進(jìn)行緩存。但是這并不意味著任何人都可以操作資源，可以設(shè)置一個(gè)保護(hù)模式，在用戶對(duì)資源進(jìn)行操作之前，進(jìn)行身份驗(yàn)證。
關(guān)于SOAP
SOAP和REST經(jīng)常被用于比較。許多人誤以為它們是等價(jià)的。實(shí)際上，他們是兩個(gè)不同的東西。這種錯(cuò)誤認(rèn)識(shí)主要源于人們認(rèn)為“REST”是通過(guò)URL調(diào)用的Web服務(wù)。而事實(shí)上，REST是一種通過(guò)對(duì)信息的解耦來(lái)管理系統(tǒng)的方法。利用REST,我們可以實(shí)現(xiàn)：
高性能
可收縮性
通用性
簡(jiǎn)化性
可修改性
可擴(kuò)展性
這并不是說(shuō)基于SOAP的系統(tǒng)不能擁有以上特性。但是，SOAP最適合的使用場(chǎng)景是，由于技術(shù)、組織或程序上的復(fù)雜性，導(dǎo)致請(qǐng)求的生命周期不能維持在單個(gè)事務(wù)范圍內(nèi)的情況。
Richardson成熟度模型
Leonard Richardson引入了成熟度模型，用于在一定程度上闡明SOAP與REST之間的區(qū)別，并且提供了一個(gè)區(qū)分不同類型系統(tǒng)的框架。我們可以把這種分類看作測(cè)定一個(gè)系統(tǒng)所包含不同的Web技術(shù)的程度：信息資源、HTTP作為應(yīng)用協(xié)議、超媒體作為控制媒介。
將其稱為“成熟模型”似乎意味著我們應(yīng)該只在最成熟的級(jí)別上構(gòu)建系統(tǒng)。其實(shí)不然，LEVEL2是有一定價(jià)值的，并且轉(zhuǎn)換到LEVEL3通常只需要采用一種新的MIME類型。即使提高ADOPTION會(huì)增加價(jià)值，但是從LEVEL0到LEVEL3的轉(zhuǎn)換仍然困難許多。
構(gòu)建RESTful的流程是，首先確定想公開(kāi)的信息資源，采用HTTP作為處理這些信息資源的應(yīng)用程序協(xié)議，包括對(duì)內(nèi)容協(xié)商的支持。然后，采用基于超媒體的MIME類型，你將體會(huì)到使用REST的所有優(yōu)點(diǎn)。
RESTful中的動(dòng)作詞匯
一般來(lái)說(shuō)，初學(xué)者們對(duì)RESTful中經(jīng)常出現(xiàn)的幾個(gè)動(dòng)作詞匯感到十分困惑。這種看似絕對(duì)的約束，實(shí)際上旨在通過(guò)非特定的方式來(lái)鼓勵(lì)可預(yù)測(cè)的行為。通過(guò)明確地定義這些行為，用戶可以在面對(duì)網(wǎng)絡(luò)中斷和故障時(shí)自主地做出決定。以下是RESTful系統(tǒng)中4個(gè)主要的HTTP動(dòng)作(有時(shí)也被叫做方法)：
GET
Web應(yīng)用中最常見(jiàn)的動(dòng)作，GET請(qǐng)求將指定的資源從服務(wù)器傳輸?shù)娇蛻舳恕Ｓ脩舨恍枰獙?duì)他請(qǐng)求的資源有任何了解。它返回的是用元數(shù)據(jù)標(biāo)記的字節(jié)碼，指示客戶端應(yīng)如何解釋它。在
Web端，這通常是“文本/html”或“應(yīng)用/xhtml+xml”。正如我們上面提到的，在使用內(nèi)容協(xié)商的情況下，只要服務(wù)器允許，用戶就可以獲得所有請(qǐng)求的資源。 ?
GET請(qǐng)求最關(guān)鍵的特征之一是他不能修改任何服務(wù)器上的數(shù)據(jù)。它是一個(gè)絕對(duì)安全的請(qǐng)求。這也是初學(xué)REST的人常犯的錯(cuò)之一。在上文提及的成熟度模型LEVEL1的系統(tǒng)中，我們經(jīng)常可以看到這樣的URL：
http://example.com/res/action=update?data=1234
千萬(wàn)不要這樣做！這是完全不符合RESTful的生態(tài)特性的。GET請(qǐng)求必須是安全的(不能修改任何數(shù)據(jù))。
此外，GET請(qǐng)求也必須是冪等的。這意味著多次執(zhí)行統(tǒng)一個(gè)請(qǐng)求總是得到相同的結(jié)果。這是在基于網(wǎng)絡(luò)的分布式系統(tǒng)中的一個(gè)非常重要的特性。如果客戶端在發(fā)出GET請(qǐng)求時(shí)被中斷，根據(jù)冪等性，該請(qǐng)求應(yīng)該被再次發(fā)出。這是非常關(guān)鍵的一點(diǎn)，因?yàn)樵谝粋€(gè)設(shè)計(jì)良好的系統(tǒng)中，什么用戶從哪個(gè)應(yīng)用發(fā)送請(qǐng)求是無(wú)關(guān)緊要的，應(yīng)用總會(huì)做出特定的響應(yīng)。但是我們?cè)蕉嗟赝七M(jìn)這種非特定于應(yīng)用程序的行為，系統(tǒng)就越有彈性且易于維護(hù)。
POST
如果僅從動(dòng)詞解釋的角度來(lái)看，POST和PUT確實(shí)沒(méi)有太大的差別，因?yàn)樗麄兌伎梢员硎緞?chuàng)建或者更新資源。然而在RESTful系統(tǒng)中，他們是完全不同的。
在用戶無(wú)法確定他想創(chuàng)建的資源的屬性時(shí)，我們需要使用POST。例如，當(dāng)我們下訂單，或者提交表單時(shí)，我們無(wú)法預(yù)測(cè)服務(wù)器會(huì)如何命名這些資源。這也是我們需要向服務(wù)器POST一個(gè)資源的指代(representation)的原因。服務(wù)器會(huì)對(duì)用戶的輸入進(jìn)行接受、驗(yàn)證等操作。如果這些操作都成功執(zhí)行，那么服務(wù)器將會(huì)返回一個(gè)HTTP201響應(yīng)。響應(yīng)的頭中包含了新創(chuàng)建的資源的位置信息。
需要注意的是，有些人把POST看作一個(gè)對(duì)話式的GET請(qǐng)求。與一般情況下返回201狀態(tài)碼不同的是，他們會(huì)設(shè)置服務(wù)器返回一個(gè)200狀態(tài)碼，并將所創(chuàng)建的資源放入內(nèi)容體。這看似是一個(gè)避免第二次請(qǐng)求的“捷徑”。但是，它將POST請(qǐng)求和GET請(qǐng)求合并在了一起，使資源的緩存變得復(fù)雜化。因此，請(qǐng)盡量避免以犧牲大局為代價(jià)去走這樣的“捷徑”。雖然短期看起來(lái)很方便，但這些“捷徑”會(huì)在將來(lái)給你帶來(lái)很大的麻煩。
POST的另外一個(gè)主要的用法是增補(bǔ)一個(gè)資源。這是一種增量編輯或者部分更新，而不是增加一個(gè)完整的新資源。舉例來(lái)說(shuō)，對(duì)一個(gè)已知資源的POST部分更新可以是，添加一個(gè)送貨地址或者是修改購(gòu)物車中商品的數(shù)量。
由于這種潛在的部分更新，POST不是一個(gè)安全、冪等的請(qǐng)求。
POST還被用在提交查詢上。查詢內(nèi)容或者URL編碼的表單值會(huì)被提交給服務(wù)器來(lái)解釋查詢。因?yàn)椴樵冎袥](méi)有關(guān)聯(lián)標(biāo)識(shí)，因此直接從這樣的POST請(qǐng)求返回的結(jié)果是合理的。
注意：可以考慮將一個(gè)查詢轉(zhuǎn)換成信息資源。一旦這樣的查詢被定義到了信息空間，我們就可以使用GET請(qǐng)求來(lái)獲取信息資源。同時(shí)我們也可以將這樣的鏈接分享給其他人。
PUT
因?yàn)镠TML表單目前暫不支持PUT，許多開(kāi)發(fā)人員在很大程度上忽略了這個(gè)請(qǐng)求。然而，它是RESTful系統(tǒng)中不可或缺的一環(huán)。用戶可以向已知URL發(fā)出PUT請(qǐng)求來(lái)完成對(duì)資源的重寫。不同于POST對(duì)資源的更新，PUT請(qǐng)求是冪等的。如果一個(gè)用戶在發(fā)送PUT請(qǐng)求時(shí)被中斷，由于冪等性，用戶完全可以重新提交一次該請(qǐng)求。
如果用戶可以預(yù)測(cè)資源的在服務(wù)器上的標(biāo)識(shí)，那么PUT也可以用來(lái)新建資源。這種情況并不常見(jiàn)(原因參照上一節(jié)在POST中的討論)，但是如果用戶端控制著服務(wù)器端的信息空間，那么這樣做也是合理的。
DELETE
在公共的Web上，DELETE沒(méi)有被大量的使用。但是他依然是RESTful生態(tài)系統(tǒng)中重要的一環(huán)。
DELETE是冪等的。如果一個(gè)DELETE請(qǐng)求被網(wǎng)絡(luò)的故障打斷，用戶可以重新提交一次請(qǐng)求。不管第一次請(qǐng)求是否成功刪除了指定資源，用戶得到的響應(yīng)都應(yīng)該是204(內(nèi)容不存在)。對(duì)于被刪除的資源或者從未存在的資源來(lái)說(shuō)，追蹤他們可能需要一些額外的處理。出于安全考慮，對(duì)于已刪除或者從未存在的資源，我們應(yīng)該返回404狀態(tài)碼，從而不泄漏任何信息。 ?
除了上文提到的4個(gè)常用的動(dòng)作，還有另外三個(gè)不常用的動(dòng)作，他們同樣重要。
HEAD
HEAD用于請(qǐng)求一個(gè)資源，但實(shí)際并不將它取回。這是客戶端檢查資源是否存在，并可能發(fā)現(xiàn)元數(shù)據(jù)的一種方式。
OPTIONS
OPTIONS可以通過(guò)詢問(wèn)其他可用的請(qǐng)求，來(lái)向服務(wù)器詢問(wèn)某個(gè)資源。
PATCH
PATCH是一種最新的HTTP方法，它只是在2010年初正式作為HTTP的一部分。它標(biāo)準(zhǔn)化的表達(dá)了對(duì)資源的部分更新。正如上文所說(shuō)，POST可以在任何場(chǎng)所被使用，然而，沒(méi)有一個(gè)明確的規(guī)范來(lái)限制什么時(shí)候要將它用于部分更新。
標(biāo)準(zhǔn)格式的PATCH請(qǐng)求允許在交互中更明確地表示請(qǐng)求的意圖。IETF(國(guó)際互聯(lián)網(wǎng)工程任務(wù)組)提出了一些RFC(請(qǐng)求評(píng)議)來(lái)修補(bǔ)XML和JSON.
如果用戶提出了一個(gè)請(qǐng)求頭為If-Match的PATCH請(qǐng)求，那么該請(qǐng)求很有可能實(shí)現(xiàn)冪等，這意味著，該請(qǐng)求被意外中斷以后是可以重啟的。因?yàn)橐坏┰撜?qǐng)求在第一次被成功執(zhí)行，那么它的If-Match請(qǐng)求頭就會(huì)與新的狀態(tài)不同。如果他們相同，則代表第一次的請(qǐng)求未被成功執(zhí)行，新的Patch請(qǐng)求將會(huì)被合理執(zhí)行。
HTTP響應(yīng)碼
HTTP的響應(yīng)碼提供了關(guān)于用戶和服務(wù)器之間請(qǐng)求的詳細(xì)診斷信息。許多人僅僅熟悉幾個(gè)響應(yīng)碼，比如200，403，404和500。事實(shí)上，實(shí)用的響應(yīng)碼還有很多很多。下表列出了一些在RESTful環(huán)境下，開(kāi)發(fā)者必須了解的響應(yīng)碼。 ?
REST資源
參考論文
Fielding博士的論文。《基于網(wǎng)絡(luò)的軟件體系結(jié)構(gòu)的架構(gòu)風(fēng)格與設(shè)計(jì)》(http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm)
一.RFC
定義REST技術(shù)規(guī)范由互聯(lián)網(wǎng)工程任務(wù)組（IETF）請(qǐng)求注釋（RFC）流程驅(qū)動(dòng)。該規(guī)格給出了各個(gè)版本的版本號(hào)，并隨著時(shí)間的推移將現(xiàn)有的舊版本更新成新版本。目前，這是最新的請(qǐng)求注釋(RFC)。
URI
RFC3986包含了URI結(jié)構(gòu)的命名方案。URI可以包括其他命名方案的編碼，如網(wǎng)站地址、命名空間、子方案等等。 ?
鏈接:[ietf.org/rfc/rfc3986.txt](ietf.org/rfc/rfc3986.txt)
URL
統(tǒng)一資源定位器（URL）是URI的一種形式。URL被嵌入了解析和定位資源(通常是訪問(wèn)方案和地址)的信息。 ?
鏈接: [ietf.org/rfc/rfc1738.txt](ietf.org/rfc/rfc1738.txt)
IRI
國(guó)際化資源標(biāo)識(shí)符（IRI）在概念上是以Unicode格式編碼的URI，以支持來(lái)自世界各地的語(yǔ)言的字符。IETF選擇創(chuàng)建一個(gè)新的標(biāo)準(zhǔn)，而不是改變URI方案本身，這樣可以在這兩種方法之間建立一個(gè)明確區(qū)分，同時(shí)不破壞現(xiàn)有的系統(tǒng)。IRI的支持者是故意為之的。因?yàn)榇嬖谝恍┦笽RI和URI相互轉(zhuǎn)化的映射方案。 ?
鏈接：[ietf.org/rfc/rfc3987.txt](ietf.org/rfc/rfc3987.txt)
HTTP
超文本傳輸協(xié)議(HTTP)在1.1版本定義了一個(gè)應(yīng)用程序協(xié)議，用于處理超媒體格式表示的信息資源。雖然它是一個(gè)應(yīng)用程序級(jí)協(xié)議，但它通常不是特定于應(yīng)用程序的，因此重要的架構(gòu)效益應(yīng)運(yùn)而生。大多數(shù)人認(rèn)為HTTP和超文本標(biāo)記語(yǔ)言（HTML）就是“Web”，但是HTTP在開(kāi)發(fā)面向非文檔的系統(tǒng)時(shí)也很有益處。 ?
鏈接：[ietf.org/rfc/rfc2616.txt](ietf.org/rfc/rfc2616.txt)
PATCH FORMATS
JavaScript Object Notation (JSON) Patch: ?
鏈接: [ietf.org/rfc/rfc6902.txt](ietf.org/rfc/rfc6902.txt) ?
XML Patch Site: ?
鏈接: [ietf.org/rfc/rfc7351.txt](ietf.org/rfc/rfc7351.txt)
描述語(yǔ)言
人們熱衷于用語(yǔ)言來(lái)描述API，以便更容易地為客戶機(jī)和服務(wù)器編寫文檔，甚至可能生成框架。下面描述一些較流行或有趣的語(yǔ)言：
RAML
一種用于描述面向LEVEL2的API的YAML/JSON語(yǔ)言。它包括對(duì)可重用模式的支持，這個(gè)特性有助于標(biāo)準(zhǔn)化API的功能設(shè)計(jì)。 ?
鏈接: [raml.org](raml.org)
SWAGGER
另一種用于描述面向LEVEL2的API的YAML/JSON語(yǔ)言。它包括代碼生成器、編輯器、API文檔的可視化以及與其他服務(wù)集成的能力。它是開(kāi)放API戰(zhàn)略的基礎(chǔ)。 ?
鏈接: [swagger.io](swagger.io) 和 [swagger.io](swagger.io)
APIARY.IO
一個(gè)協(xié)作的托管站點(diǎn)，支持基于Markdown的API文檔，圍繞設(shè)計(jì)過(guò)程進(jìn)行的交互，以及對(duì)模擬托管實(shí)施的支持，以便在實(shí)施之前輕松測(cè)試API。 ?
鏈接: [apiary.io](apiary.io)
HYDRA-CG
它是一種超媒體描述語(yǔ)言。它通過(guò)某些標(biāo)準(zhǔn)(比如json-ld)，使得自己對(duì)數(shù)據(jù)鏈接的支持、與其他數(shù)據(jù)源的交互更為容易。 ?
鏈接: [hydra-cg.com](hydra-cg.com)
二.實(shí)際應(yīng)用
有幾個(gè)庫(kù)和框架可用于構(gòu)建生成和使用REST系統(tǒng)的系統(tǒng)。
現(xiàn)在有許多庫(kù)和框架可構(gòu)建使用RESTful的系統(tǒng)。雖然任何Web服務(wù)器都可以配置REST API，但使用這些框架和庫(kù)更為方便。下面是一些主要環(huán)境的概述：
JAX-RS:
該規(guī)范增加了JEE對(duì)REST的支持。 ?
鏈接: [jax-rs-spec.java.net](jax-rs-spec.java.net)
RESTLET:
Restlet API是在RESTful系統(tǒng)上建立Java API的先期嘗試之一。他的重點(diǎn)在于建立一套在用戶端和服務(wù)器端功能對(duì)等的既簡(jiǎn)明而又功能強(qiáng)大的API。Restlet Studio是一款免費(fèi)的工具，他允許RAML和基于Swagger的API之間的轉(zhuǎn)換，同時(shí)支持Restlet, Node和JAX-RS。 ?
鏈接：[restlet.org](restlet.org)
NETKERNEL:
NetKernel是一套非常有意思的RESTful系統(tǒng)，他支持各種架構(gòu)風(fēng)格的微核環(huán)境。它得益于在軟件體系結(jié)構(gòu)中采用Web的經(jīng)濟(jì)學(xué)特性。你可以認(rèn)為他是一種“引進(jìn)的REST”。然而，RESTful的系統(tǒng)在外部看起來(lái)相差都不大，NetKernel也是如此。 ?
鏈接: [netkernel.org](netkernel.org)
PLAY:
當(dāng)前有兩個(gè)主要的Scala語(yǔ)言REST框架。PLAY就是其中之一。 ?
鏈接:[playframework.com](playframework.com)
SPRAY:
另外一個(gè)Scala語(yǔ)言REST框架。主要運(yùn)作于Akka模式。 ?
鏈接: [spray.io](spray.io)
EXPRESS:
Node.js的REST框架。 ?
鏈接: [expressjs.com](expressjs.com)
HAPI:
另一個(gè)Node.js的REST框架。 ?
鏈接: [hapijs.com](hapijs.com)
SINATRA:
Ruby的RESTful框架。 ?
鏈接: [sinatrarb.com](sinatrarb.com)
三.客戶端工具
我們的確可以使用瀏覽器來(lái)調(diào)用REST，但是在創(chuàng)建和測(cè)試面向資源的系統(tǒng)中，使用一些客戶端工具是更為方便和高效的。
CURL:
CURL是一種廣受歡迎的命令行工具，它可以調(diào)用各種資源上的各種協(xié)議。 ?
鏈接: [curl.haxx.se](curl.haxx.se)
HTTPIE:
HTTPIE是一款非常靈活，易于使用的客戶端工具。它通過(guò)HTTP進(jìn)行資源的交互。
鏈接: [httpie.org](httpie.org)
POSTMAN:
POSTMAN是一款全面的API測(cè)試工具。它可以捕獲和重置各種請(qǐng)求，使用各種授權(quán)認(rèn)證。一些早期的命令行工具也可以實(shí)現(xiàn)需要的大部分功能，但是POSTMAN作為一款全新的桌面應(yīng)用，他大大的降低了開(kāi)發(fā)者的工作量，提高了工作效率。 ?
原文地址：https://dzone.com/refcardz/rest-foundations-restful
.NET社區(qū)新聞，深度好文，微信中搜索dotNET跨平臺(tái)或掃描二維碼關(guān)注
總結(jié)
- 上一篇： DotNetCore跨平台~Docker
- 下一篇： Docker~从Dockerfile到C