REST API設(shè)計(jì)風(fēng)格都有哪些，很多新手對(duì)此不是很清楚，為了幫助大家解決這個(gè)難題，下面小編將為大家詳細(xì)講解，有這方面需求的人可以來(lái)學(xué)習(xí)下，希望你能有所收獲。

創(chuàng)新互聯(lián)服務(wù)項(xiàng)目包括保定網(wǎng)站建設(shè)、保定網(wǎng)站制作、保定網(wǎng)頁(yè)制作以及保定網(wǎng)絡(luò)營(yíng)銷(xiāo)策劃等。多年來(lái)，我們專(zhuān)注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術(shù)優(yōu)勢(shì)、行業(yè)經(jīng)驗(yàn)、深度合作伙伴關(guān)系等，向廣大中小型企業(yè)、政府機(jī)構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案，保定網(wǎng)站推廣取得了明顯的社會(huì)效益與經(jīng)濟(jì)效益。目前，我們服務(wù)的客戶(hù)以成都為中心已經(jīng)輻射到保定省份的部分城市，未來(lái)相信會(huì)繼續(xù)擴(kuò)大服務(wù)區(qū)域并繼續(xù)獲得客戶(hù)的支持與信任！

如果你研究了應(yīng)用程序中當(dāng)前定義的所有路由，會(huì)注意到其中的幾個(gè)符合我上面使用的API的定義。找到它們了嗎？我說(shuō)的是返回JSON的幾條路由，比如第十四章中定義的/translate路由。這種路由的內(nèi)容都以JSON格式編碼，并在請(qǐng)求時(shí)使用POST方法。此請(qǐng)求的響應(yīng)也是JSON格式，服務(wù)器僅返回所請(qǐng)求的信息，客戶(hù)端負(fù)責(zé)將此信息呈現(xiàn)給用戶(hù)。

雖然應(yīng)用程序中的JSON路由具有API的“感覺(jué)”，但它們的設(shè)計(jì)初衷是為支持在瀏覽器中運(yùn)行的Web應(yīng)用程序。設(shè)想一下，如果智能手機(jī)APP想要使用這些路由，它將無(wú)法使用，因?yàn)檫@需要用戶(hù)登錄，而登錄只能通過(guò)HTML表單進(jìn)行。在本章中，我將展示如何構(gòu)建不依賴(lài)于Web瀏覽器的API，并且不會(huì)假設(shè)連接到它們的客戶(hù)端的類(lèi)型。

分層系統(tǒng)

分層系統(tǒng)原則是說(shuō)當(dāng)客戶(hù)端需要與服務(wù)器通信時(shí)，它可能最終連接到代理服務(wù)器而不是實(shí)際的服務(wù)器。因此，對(duì)于客戶(hù)端來(lái)說(shuō)，如果不直接連接到服務(wù)器，它發(fā)送請(qǐng)求的方式應(yīng)該沒(méi)有什么區(qū)別，事實(shí)上，它甚至可能不知道它是否連接到目標(biāo)服務(wù)器。同樣，這個(gè)原則規(guī)定服務(wù)器兼容直接接收來(lái)自代理服務(wù)器的請(qǐng)求，所以它絕不能假設(shè)連接的另一端一定是客戶(hù)端。

這是REST的一個(gè)重要特性，因?yàn)槟軌蛱砑又虚g節(jié)點(diǎn)的這個(gè)特性，允許應(yīng)用程序架構(gòu)師使用負(fù)載均衡器，緩存，代理服務(wù)器等來(lái)設(shè)計(jì)滿(mǎn)足大量請(qǐng)求的大型復(fù)雜網(wǎng)絡(luò)。

按需獲取客戶(hù)端代碼（CodeOnDemand）

這是一項(xiàng)可選要求，規(guī)定服務(wù)器可以提供可執(zhí)行代碼以響應(yīng)客戶(hù)端，這樣一來(lái)，就可以從服務(wù)器上獲取客戶(hù)端的新功能。因?yàn)檫@個(gè)原則需要服務(wù)器和客戶(hù)端之間就客戶(hù)端能夠運(yùn)行的可執(zhí)行代碼類(lèi)型達(dá)成一致，所以這在API中很少使用。你可能會(huì)認(rèn)為服務(wù)器可能會(huì)返回JavaScript代碼以供Web瀏覽器客戶(hù)端執(zhí)行，但REST并非專(zhuān)門(mén)針對(duì)Web瀏覽器客戶(hù)端而設(shè)計(jì)。例如，如果客戶(hù)端是iOS或Android設(shè)備，執(zhí)行JavaScript可能會(huì)帶來(lái)一些復(fù)雜情況。

統(tǒng)一接口

最后，最重要的，最有爭(zhēng)議的，最含糊不清的REST原則是統(tǒng)一接口。Dr.Fielding列舉了REST統(tǒng)一接口的四個(gè)特性：唯一資源標(biāo)識(shí)符，資源表示，自描述性消息和超媒體。

唯一資源標(biāo)識(shí)符是通過(guò)為每個(gè)資源分配唯一的URL來(lái)實(shí)現(xiàn)的。例如，與給定用戶(hù)關(guān)聯(lián)的URL可以是/api/users/，其中是在數(shù)據(jù)庫(kù)表主鍵中分配給用戶(hù)的標(biāo)識(shí)符。大多數(shù)API都能很好地實(shí)現(xiàn)這一點(diǎn)。

資源表示的使用意味著當(dāng)服務(wù)器和客戶(hù)端交換關(guān)于資源的信息時(shí)，他們必須使用商定的格式。對(duì)于大多數(shù)現(xiàn)代API，JSON格式用于構(gòu)建資源表示。API可以選擇支持多種資源表示格式，并且在這種情況下，HTTP協(xié)議中的內(nèi)容協(xié)商選項(xiàng)是客戶(hù)端和服務(wù)器確認(rèn)格式的機(jī)制。

自描述性消息意味著在客戶(hù)端和服務(wù)器之間交換的請(qǐng)求和響應(yīng)必須包含對(duì)方需要的所有信息。作為一個(gè)典型的例子，HTTP請(qǐng)求方法用于指示客戶(hù)端希望服務(wù)器執(zhí)行的操作。GET請(qǐng)求表示客戶(hù)想要檢索資源信息，POST請(qǐng)求表示客戶(hù)想要?jiǎng)?chuàng)建新資源，PUT或PATCH請(qǐng)求定義對(duì)現(xiàn)有資源的修改，DELETE表示刪除資源的請(qǐng)求。目標(biāo)資源被指定為請(qǐng)求的URL，并在HTTP頭，URL的查詢(xún)字符串部分或請(qǐng)求主體中提供附加信息。

超媒體需求是最具爭(zhēng)議性的，而且很少有API實(shí)現(xiàn)，而那些實(shí)現(xiàn)它的API很少以滿(mǎn)足REST純粹主義者的方式進(jìn)行。由于應(yīng)用程序中的資源都是相互關(guān)聯(lián)的，因此此要求會(huì)要求將這些關(guān)系包含在資源表示中，以便客戶(hù)端可以通過(guò)遍歷關(guān)系來(lái)發(fā)現(xiàn)新資源，這幾乎與你在Web應(yīng)用程序中通過(guò)點(diǎn)擊從一個(gè)頁(yè)面到另一個(gè)頁(yè)面的鏈接來(lái)發(fā)現(xiàn)新頁(yè)面的方式相同。理想情況下，客戶(hù)端可以輸入一個(gè)API，而不需要任何有關(guān)其中的資源的信息，就可以簡(jiǎn)單地通過(guò)超媒體鏈接來(lái)了解它們。但是，與HTML和XML不同，通常用于API中資源表示的JSON格式?jīng)]有定義包含鏈接的標(biāo)準(zhǔn)方式，因此你不得不使用自定義結(jié)構(gòu)，或者類(lèi)似JSON-API，HAL，JSON-LD這樣的試圖解決這種差距的JSON擴(kuò)展之一。

看完上述內(nèi)容是否對(duì)您有幫助呢？如果還想對(duì)相關(guān)知識(shí)有進(jìn)一步的了解或閱讀更多相關(guān)文章，請(qǐng)關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝您對(duì)創(chuàng)新互聯(lián)的支持。