中文字幕一区二区人妻电影,亚洲av无码一区二区乱子伦as ,亚洲精品无码永久在线观看,亚洲成aⅴ人片久青草影院按摩,亚洲黑人巨大videos

上一篇：Express 4.x API 中文文檔 下一篇：無(wú)

RESTful 架構(gòu)詳解

1. 什么是REST

restful

REST全稱(chēng)是Representational State Transfer，中文意思是表述（編者注：通常譯為表征）性狀態(tài)轉(zhuǎn)移。 它首次出現(xiàn)在2000年Roy Fielding的博士論文中，Roy Fielding是HTTP規(guī)范的主要編寫(xiě)者之一。 他在論文中提到："我這篇文章的寫(xiě)作目的，就是想在符合架構(gòu)原理的前提下，理解和評(píng)估以網(wǎng)絡(luò)為基礎(chǔ)的應(yīng)用軟件的架構(gòu)設(shè)計(jì)，得到一個(gè)功能強(qiáng)、性能好、適宜通信的架構(gòu)。REST指的是一組架構(gòu)約束條件和原則。" 如果一個(gè)架構(gòu)符合REST的約束條件和原則，我們就稱(chēng)它為RESTful架構(gòu)。

REST本身并沒(méi)有創(chuàng)造新的技術(shù)、組件或服務(wù)，而隱藏在RESTful背后的理念就是使用Web的現(xiàn)有特征和能力， 更好地使用現(xiàn)有Web標(biāo)準(zhǔn)中的一些準(zhǔn)則和約束。雖然REST本身受Web技術(shù)的影響很深， 但是理論上REST架構(gòu)風(fēng)格并不是綁定在HTTP上，只不過(guò)目前HTTP是唯一與REST相關(guān)的實(shí)例。 所以我們這里描述的REST也是通過(guò)HTTP實(shí)現(xiàn)的REST。

2. 理解RESTful

要理解RESTful架構(gòu)，需要理解Representational State Transfer這個(gè)詞組到底是什么意思，它的每一個(gè)詞都有些什么涵義。

下面我們結(jié)合REST原則，圍繞資源展開(kāi)討論，從資源的定義、獲取、表述、關(guān)聯(lián)、狀態(tài)變遷等角度，列舉一些關(guān)鍵概念并加以解釋。

  • 資源與URI
  • 統(tǒng)一資源接口
  • 資源的表述
  • 資源的鏈接
  • 狀態(tài)的轉(zhuǎn)移

2. 1 資源與URI

REST全稱(chēng)是表述性狀態(tài)轉(zhuǎn)移，那究竟指的是什么的表述? 其實(shí)指的就是資源。任何事物，只要有被引用到的必要，它就是一個(gè)資源。資源可以是實(shí)體(例如手機(jī)號(hào)碼)，也可以只是一個(gè)抽象概念(例如價(jià)值) 。下面是一些資源的例子：

  • 某用戶(hù)的手機(jī)號(hào)碼
  • 某用戶(hù)的個(gè)人信息
  • 最多用戶(hù)訂購(gòu)的GPRS套餐
  • 兩個(gè)產(chǎn)品之間的依賴(lài)關(guān)系
  • 某用戶(hù)可以辦理的優(yōu)惠套餐
  • 某手機(jī)號(hào)碼的潛在價(jià)值

要讓一個(gè)資源可以被識(shí)別，需要有個(gè)唯一標(biāo)識(shí)，在Web中這個(gè)唯一標(biāo)識(shí)就是URI(Uniform Resource Identifier)。

URI既可以看成是資源的地址，也可以看成是資源的名稱(chēng)。如果某些信息沒(méi)有使用URI來(lái)表示，那它就不能算是一個(gè)資源， 只能算是資源的一些信息而已。URI的設(shè)計(jì)應(yīng)該遵循可尋址性原則，具有自描述性，需要在形式上給人以直覺(jué)上的關(guān)聯(lián)。這里以github網(wǎng)站為例，給出一些還算不錯(cuò)的URI：

  • https://github.com/git
  • https://github.com/git/git
  • https://github.com/git/git/blob/master/block-sha1/sha1.h
  • https://github.com/git/git/commit/e3af72cdafab5993d18fae056f87e1d675913d08
  • https://github.com/git/git/pulls
  • https://github.com/git/git/pulls?state=closed
  • https://github.com/git/git/compare/master…next

下面讓我們來(lái)看看URI設(shè)計(jì)上的一些技巧:

  • 使用_或-來(lái)讓URI可讀性更好

曾經(jīng)Web上的URI都是冰冷的數(shù)字或者無(wú)意義的字符串，但現(xiàn)在越來(lái)越多的網(wǎng)站使用_或-來(lái)分隔一些單詞，讓URI看上去更為人性化。 例如國(guó)內(nèi)比較出名的開(kāi)源中國(guó)社區(qū)，它上面的新聞地址就采用這種風(fēng)格， 如http://www.oschina.net/news/38119/oschina-translate-reward-plan。

  • 使用/來(lái)表示資源的層級(jí)關(guān)系

例如上述/git/git/commit/e3af72cdafab5993d18fae056f87e1d675913d08就表示了一個(gè)多級(jí)的資源， 指的是git用戶(hù)的git項(xiàng)目的某次提交記錄，又例如/orders/2012/10可以用來(lái)表示2012年10月的訂單記錄。

  • 使用?用來(lái)過(guò)濾資源

很多人只是把?簡(jiǎn)單的當(dāng)做是參數(shù)的傳遞，很容易造成URI過(guò)于復(fù)雜、難以理解?？梢园?用于對(duì)資源的過(guò)濾， 例如/git/git/pulls用來(lái)表示git項(xiàng)目的所有推入請(qǐng)求，而/pulls?state=closed用來(lái)表示git項(xiàng)目中已經(jīng)關(guān)閉的推入請(qǐng)求， 這種URL通常對(duì)應(yīng)的是一些特定條件的查詢(xún)結(jié)果或算法運(yùn)算結(jié)果。

  • ,或;可以用來(lái)表示同級(jí)資源的關(guān)系

有時(shí)候我們需要表示同級(jí)資源的關(guān)系時(shí)，可以使用,或;來(lái)進(jìn)行分割。例如哪天github可以比較某個(gè)文件在隨意兩次提交記錄之間的差異，或許可以使用/git/git /block-sha1/sha1.h/compare/e3af72cdafab5993d18fae056f87e1d675913d08;bd63e61bdf38e872d5215c07b264dcc16e4febca作為URI。 不過(guò)，現(xiàn)在github是使用…來(lái)做這個(gè)事情的，例如/git/git/compare/master…next。

2. 2 統(tǒng)一資源接口

RESTful架構(gòu)應(yīng)該遵循統(tǒng)一接口原則，統(tǒng)一接口包含了一組受限的預(yù)定義的操作，不論什么樣的資源，都是通過(guò)使用相同的接口進(jìn)行資源的訪問(wèn)。接口應(yīng)該使用標(biāo)準(zhǔn)的HTTP方法如GET，PUT和POST，并遵循這些方法的語(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é)果總是一樣的，后面的請(qǐng)求并不會(huì)產(chǎn)生比第一次更多的影響。

下面列出了GET，DELETE，PUT和POST的典型用法:

GET

  • 安全且冪等
  • 獲取表示
  • 變更時(shí)獲取表示（緩存）
  • 200（OK） - 表示已在響應(yīng)中發(fā)出
  • 204（無(wú)內(nèi)容） - 資源有空表示
  • 301（Moved Permanently） - 資源的URI已被更新
  • 303（See Other） - 其他（如，負(fù)載均衡）
  • 304（not modified）- 資源未更改（緩存）
  • 400 （bad request）- 指代壞請(qǐng)求（如，參數(shù)錯(cuò)誤）
  • 404 （not found）- 資源不存在
  • 406 （not acceptable）- 服務(wù)端不支持所需表示
  • 500 （internal server error）- 通用錯(cuò)誤響應(yīng)
  • 503 （Service Unavailable）- 服務(wù)端當(dāng)前無(wú)法處理請(qǐng)求

POST

  • 不安全且不冪等
  • 使用服務(wù)端管理的（自動(dòng)產(chǎn)生）的實(shí)例號(hào)創(chuàng)建資源
  • 創(chuàng)建子資源
  • 部分更新資源
  • 如果沒(méi)有被修改，則不過(guò)更新資源（樂(lè)觀鎖）
  • 200（OK）- 如果現(xiàn)有資源已被更改
  • 201（created）- 如果新資源被創(chuàng)建
  • 202（accepted）- 已接受處理請(qǐng)求但尚未完成（異步處理）
  • 301（Moved Permanently）- 資源的URI被更新
  • 303（See Other）- 其他（如，負(fù)載均衡）
  • 400（bad request）- 指代壞請(qǐng)求
  • 404 （not found）- 資源不存在
  • 406 （not acceptable）- 服務(wù)端不支持所需表示
  • 409 （conflict）- 通用沖突
  • 412 （Precondition Failed）- 前置條件失敗（如執(zhí)行條件更新時(shí)的沖突）
  • 415 （unsupported media type）- 接受到的表示不受支持
  • 500 （internal server error）- 通用錯(cuò)誤響應(yīng)
  • 503 （Service Unavailable）- 服務(wù)當(dāng)前無(wú)法處理請(qǐng)求

PUT

  • 不安全但冪等
  • 用客戶(hù)端管理的實(shí)例號(hào)創(chuàng)建一個(gè)資源
  • 通過(guò)替換的方式更新資源
  • 如果未被修改，則更新資源（樂(lè)觀鎖）
  • 200 （OK）- 如果已存在資源被更改
  • 201 （created）- 如果新資源被創(chuàng)建
  • 301（Moved Permanently）- 資源的URI已更改
  • 303 （See Other）- 其他（如，負(fù)載均衡）
  • 400 （bad request）- 指代壞請(qǐng)求
  • 404 （not found）- 資源不存在
  • 406 （not acceptable）- 服務(wù)端不支持所需表示
  • 409 （conflict）- 通用沖突
  • 412 （Precondition Failed）- 前置條件失敗（如執(zhí)行條件更新時(shí)的沖突）
  • 415 （unsupported media type）- 接受到的表示不受支持
  • 500 （internal server error）- 通用錯(cuò)誤響應(yīng)
  • 503 （Service Unavailable）- 服務(wù)當(dāng)前無(wú)法處理請(qǐng)求

DELETE

  • 不安全但冪等
  • 刪除資源
  • 200 （OK）- 資源已被刪除
  • 301 （Moved Permanently）- 資源的URI已更改
  • 303 （See Other）- 其他，如負(fù)載均衡
  • 400 （bad request）- 指代壞請(qǐng)求
  • 404 （not found）- 資源不存在
  • 409 （conflict）- 通用沖突
  • 500 （internal server error）- 通用錯(cuò)誤響應(yīng)
  • 503 （Service Unavailable）- 服務(wù)端當(dāng)前無(wú)法處理請(qǐng)求

下面我們來(lái)看一些實(shí)踐中常見(jiàn)的問(wèn)題:

  • POST和PUT用于創(chuàng)建資源時(shí)有什么區(qū)別?

POST和PUT在創(chuàng)建資源的區(qū)別在于，所創(chuàng)建的資源的名稱(chēng)(URI)是否由客戶(hù)端決定。 例如為我的博文增加一個(gè)java的分類(lèi)，生成的路徑就是分類(lèi)名/categories/java，那么就可以采用PUT方法。不過(guò)很多人直接把POST、GET、PUT、DELETE直接對(duì)應(yīng)上CRUD，例如在一個(gè)典型的rails實(shí)現(xiàn)的RESTful應(yīng)用中就是這么做的。

我認(rèn)為，這是因?yàn)閞ails默認(rèn)使用服務(wù)端生成的ID作為URI的緣故，而不少人就是通過(guò)rails實(shí)踐REST的，所以很容易造成這種誤解。

  • 客戶(hù)端不一定都支持這些HTTP方法吧?

的確有這種情況，特別是一些比較古老的基于瀏覽器的客戶(hù)端，只能支持GET和POST兩種方法。

在實(shí)踐上，客戶(hù)端和服務(wù)端都可能需要做一些妥協(xié)。例如rails框架就支持通過(guò)隱藏參數(shù)_method=DELETE來(lái)傳遞真實(shí)的請(qǐng)求方法， 而像Backbone這樣的客戶(hù)端MVC框架則允許傳遞_method傳輸和設(shè)置X-HTTP-Method-Override頭來(lái)規(guī)避這個(gè)問(wèn)題。

  • 統(tǒng)一接口是否意味著不能擴(kuò)展帶特殊語(yǔ)義的方法?

統(tǒng)一接口并不阻止你擴(kuò)展方法，只要方法對(duì)資源的操作有著具體的、可識(shí)別的語(yǔ)義即可，并能夠保持整個(gè)接口的統(tǒng)一性。

像WebDAV就對(duì)HTTP方法進(jìn)行了擴(kuò)展，增加了LOCK、UPLOCK等方法。而github的API則支持使用PATCH方法來(lái)進(jìn)行issue的更新，例如:

PATCH /repos/:owner/:repo/issues/:number

不過(guò)，需要注意的是，像PATCH這種不是HTTP標(biāo)準(zhǔn)方法的，服務(wù)端需要考慮客戶(hù)端是否能夠支持的問(wèn)題。

  • 統(tǒng)一資源接口對(duì)URI有什么指導(dǎo)意義?

統(tǒng)一資源接口要求使用標(biāo)準(zhǔn)的HTTP方法對(duì)資源進(jìn)行操作，所以URI只應(yīng)該來(lái)表示資源的名稱(chēng)，而不應(yīng)該包括資源的操作。

通俗來(lái)說(shuō)，URI不應(yīng)該使用動(dòng)作來(lái)描述。例如，下面是一些不符合統(tǒng)一接口要求的URI:

  • GET /getUser/1
  • POST /createUser
  • PUT /updateUser/1
  • DELETE /deleteUser/1

如果GET請(qǐng)求增加計(jì)數(shù)器，這是否違反安全性?

安全性不代表請(qǐng)求不產(chǎn)生副作用，例如像很多API開(kāi)發(fā)平臺(tái)，都對(duì)請(qǐng)求流量做限制。像github，就會(huì)限制沒(méi)有認(rèn)證的請(qǐng)求每小時(shí)只能請(qǐng)求60次。

但客戶(hù)端不是為了追求副作用而發(fā)出這些GET或HEAD請(qǐng)求的，產(chǎn)生副作用是服務(wù)端"自作主張"的。

另外，服務(wù)端在設(shè)計(jì)時(shí)，也不應(yīng)該讓副作用太大，因?yàn)榭蛻?hù)端認(rèn)為這些請(qǐng)求是不會(huì)產(chǎn)生副作用的。

  • 直接忽視緩存可取嗎?

即使你按各個(gè)動(dòng)詞的原本意圖來(lái)使用它們，你仍可以輕易禁止緩存機(jī)制。 最簡(jiǎn)單的做法就是在你的HTTP響應(yīng)里增加這樣一個(gè)報(bào)頭： Cache-control: no-cache。 但是，同時(shí)你也對(duì)失去了高效的緩存與再驗(yàn)證的支持(使用Etag等機(jī)制)。

對(duì)于客戶(hù)端來(lái)說(shuō)，在為一個(gè)REST式服務(wù)實(shí)現(xiàn)程序客戶(hù)端時(shí)，也應(yīng)該充分利用現(xiàn)有的緩存機(jī)制，以免每次都重新獲取表示。

  • 響應(yīng)代碼的處理有必要嗎?

HTTP的響應(yīng)代碼可用于應(yīng)付不同場(chǎng)合，正確使用這些狀態(tài)代碼意味著客戶(hù)端與服務(wù)器可以在一個(gè)具備較豐富語(yǔ)義的層次上進(jìn)行溝通。

例如，201（"Created"）響應(yīng)代碼表明已經(jīng)創(chuàng)建了一個(gè)新的資源，其URI在Location響應(yīng)報(bào)頭里。

假如你不利用HTTP狀態(tài)代碼豐富的應(yīng)用語(yǔ)義，那么你將錯(cuò)失提高重用性、增強(qiáng)互操作性和提升松耦合性的機(jī)會(huì)。

如果這些所謂的RESTful應(yīng)用必須通過(guò)響應(yīng)實(shí)體才能給出錯(cuò)誤信息，那么SOAP就是這樣的了，它就能夠滿(mǎn)足了。

2. 3 資源的表述

上面提到，客戶(hù)端通過(guò)HTTP方法可以獲取資源，是吧? 不，確切的說(shuō)，客戶(hù)端獲取的只是資源的表述而已。 資源在外界的具體呈現(xiàn)，可以有多種表述(或成為表現(xiàn)、表示)形式，在客戶(hù)端和服務(wù)端之間傳送的也是資源的表述，而不是資源本身。 例如文本資源可以采用html、xml、json等格式，圖片可以使用PNG或JPG展現(xiàn)出來(lái)。

資源的表述包括數(shù)據(jù)和描述數(shù)據(jù)的元數(shù)據(jù)，例如，HTTP頭"Content-Type" 就是這樣一個(gè)元數(shù)據(jù)屬性。

那么客戶(hù)端如何知道服務(wù)端提供哪種表述形式呢?

答案是可以通過(guò)HTTP內(nèi)容協(xié)商，客戶(hù)端可以通過(guò)Accept頭請(qǐng)求一種特定格式的表述，服務(wù)端則通過(guò)Content-Type告訴客戶(hù)端資源的表述形式。

以github為例，請(qǐng)求某組織資源的json格式的表述形式:

291731048886033

　

　假如github也能夠支持xml格式的表述格式，那么結(jié)果就是這樣的:

291731045756062

　

　下面我們來(lái)看一些實(shí)踐上常見(jiàn)的設(shè)計(jì):

在URI里邊帶上版本號(hào)

有些API在URI里邊帶上版本號(hào)，例如:

  • http://api.example.com/1.0/foo
  • http://api.example.com/1.2/foo
  • http://api.example.com/2.0/foo

如果我們把版本號(hào)理解成資源的不同表述形式的話，就應(yīng)該只是用一個(gè)URL，并通過(guò)Accept頭部來(lái)區(qū)分，還是以github為例，它的Accept的完整格式是:application/vnd.github[.version].param[+json]

對(duì)于v3版本的話，就是Accept: application/vnd.github.v3。對(duì)于上面的例子，同理可以使用使用下面的頭部:

  • Accept: vnd.example-com.foo+json; version=1.0
  • Accept: vnd.example-com.foo+json; version=1.2
  • Accept: vnd.example-com.foo+json; version=2.0

使用URI后綴來(lái)區(qū)分表述格式

像rails框架，就支持使用/users.xml或/users.json來(lái)區(qū)分不同的格式。 這樣的方式對(duì)于客戶(hù)端來(lái)說(shuō)，無(wú)疑是更為直觀，但混淆了資源的名稱(chēng)和資源的表述形式。 我個(gè)人認(rèn)為，還是應(yīng)該優(yōu)先使用內(nèi)容協(xié)商來(lái)區(qū)分表述格式。

如何處理不支持的表述格式

當(dāng)服務(wù)器不支持所請(qǐng)求的表述格式，那么應(yīng)該怎么辦？若服務(wù)器不支持，它應(yīng)該返回一個(gè)HTTP 406響應(yīng)，表示拒絕處理該請(qǐng)求。下面以github為例，展示了一個(gè)請(qǐng)求XML表述資源的結(jié)果：

291732082474844

　　

2. 4 資源的鏈接

我們知道REST是使用標(biāo)準(zhǔn)的HTTP方法來(lái)操作資源的，但僅僅因此就理解成帶CURD的Web數(shù)據(jù)庫(kù)架構(gòu)就太過(guò)于簡(jiǎn)單了。

這種反模式忽略了一個(gè)核心概念："超媒體即應(yīng)用狀態(tài)引擎（hypermedia as the engine of application state）"。 超媒體是什么?

當(dāng)你瀏覽Web網(wǎng)頁(yè)時(shí)，從一個(gè)連接跳到一個(gè)頁(yè)面，再?gòu)牧硪粋€(gè)連接跳到另外一個(gè)頁(yè)面，就是利用了超媒體的概念：把一個(gè)個(gè)把資源鏈接起來(lái).

要達(dá)到這個(gè)目的，就要求在表述格式里邊加入鏈接來(lái)引導(dǎo)客戶(hù)端。在《RESTful Web Services》一書(shū)中，作者把這種具有鏈接的特性成為連通性。下面我們具體來(lái)看一些例子。

下面展示的是github獲取某個(gè)組織下的項(xiàng)目列表的請(qǐng)求，可以看到在響應(yīng)頭里邊增加Link頭告訴客戶(hù)端怎么訪問(wèn)下一頁(yè)和最后一頁(yè)的記錄。 而在響應(yīng)體里邊，用url來(lái)鏈接項(xiàng)目所有者和項(xiàng)目地址。

291731042784620

　　又例如下面這個(gè)例子，創(chuàng)建訂單后通過(guò)鏈接引導(dǎo)客戶(hù)端如何去付款。

291731052313462

上面的例子展示了如何使用超媒體來(lái)增強(qiáng)資源的連通性。很多人在設(shè)計(jì)RESTful架構(gòu)時(shí)，使用很多時(shí)間來(lái)尋找漂亮的URI，而忽略了超媒體。所以，應(yīng)該多花一些時(shí)間來(lái)給資源的表述提供鏈接，而不是專(zhuān)注于"資源的CRUD"。

2. 5 狀態(tài)的轉(zhuǎn)移

有了上面的鋪墊，再討論REST里邊的狀態(tài)轉(zhuǎn)移就會(huì)很容易理解了。

不過(guò)，我們先來(lái)討論一下REST原則中的無(wú)狀態(tài)通信原則。初看一下，好像自相矛盾了，既然無(wú)狀態(tài)，何來(lái)狀態(tài)轉(zhuǎn)移一說(shuō)?

其實(shí)，這里說(shuō)的無(wú)狀態(tài)通信原則，并不是說(shuō)客戶(hù)端應(yīng)用不能有狀態(tài)，而是指服務(wù)端不應(yīng)該保存客戶(hù)端狀態(tài)。

2. 5.1 應(yīng)用狀態(tài)與資源狀態(tài)

實(shí)際上，狀態(tài)應(yīng)該區(qū)分應(yīng)用狀態(tài)和資源狀態(tài)，客戶(hù)端負(fù)責(zé)維護(hù)應(yīng)用狀態(tài)，而服務(wù)端維護(hù)資源狀態(tài)。

客戶(hù)端與服務(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)求中，同一客戶(hù)端也不再需要依賴(lài)于同一服務(wù)器，方便實(shí)現(xiàn)高可擴(kuò)展和高可用性的服務(wù)端。

但有時(shí)候我們會(huì)做出違反無(wú)狀態(tài)通信原則的設(shè)計(jì)，例如利用Cookie跟蹤某個(gè)服務(wù)端會(huì)話狀態(tài)，常見(jiàn)的像J2EE里邊的JSESSIONID。

這意味著，瀏覽器隨各次請(qǐng)求發(fā)出去的Cookie是被用于構(gòu)建會(huì)話狀態(tài)的。

當(dāng)然，如果Cookie保存的是一些服務(wù)器不依賴(lài)于會(huì)話狀態(tài)即可驗(yàn)證的信息（比如認(rèn)證令牌），這樣的Cookie也是符合REST原則的。

2. 5.2 應(yīng)用狀態(tài)的轉(zhuǎn)移

狀態(tài)轉(zhuǎn)移到這里已經(jīng)很好理解了， "會(huì)話"狀態(tài)不是作為資源狀態(tài)保存在服務(wù)端的，而是被客戶(hù)端作為應(yīng)用狀態(tài)進(jìn)行跟蹤的?？蛻?hù)端應(yīng)用狀態(tài)在服務(wù)端提供的超媒體的指引下發(fā)生變遷。服務(wù)端通過(guò)超媒體告訴客戶(hù)端當(dāng)前狀態(tài)有哪些后續(xù)狀態(tài)可以進(jìn)入。

這些類(lèi)似"下一頁(yè)"之類(lèi)的鏈接起的就是這種推進(jìn)狀態(tài)的作用——指引你如何從當(dāng)前狀態(tài)進(jìn)入下一個(gè)可能的狀態(tài)。

3. 總結(jié)

現(xiàn)在廣東XXX版本、XXX等項(xiàng)目中均使用傳統(tǒng)的RPC、SOAP方式的Web服務(wù)，而移動(dòng)南方基地XXXX項(xiàng)目的后臺(tái)， 雖然采用了JSON格式進(jìn)行交互，但還是屬于RPC風(fēng)格的。本文從資源的定義、獲取、表述、關(guān)聯(lián)、狀態(tài)變遷等角度， 試圖快速理解RESTful架構(gòu)背后的概念。RESTful架構(gòu)與傳統(tǒng)的RPC、SOAP等方式在理念上有很大的不同，希望本文能對(duì)各位理解REST有所幫助。

上一篇：Express 4.x API 中文文檔 下一篇：無(wú)