RESTful的實現(xiàn)

申請免費試用、咨詢電話：400-8352-114

REST (REpresentation State Transfer) 描繪了一個架構(gòu)款式的收集系統(tǒng)，比方 web 使用順序。它初次呈現(xiàn)在 2000 年 Roy Fielding 的博士論文中，他是 HTTP 標(biāo)準的首要編寫者之一。REST 指的是一組架構(gòu)約束前提和準則。知足這些約束前提和準則的使用順序或設(shè)計就是 RESTful。

Web 使用順序最主要的 REST 準則是，客戶端和效勞器之間的交互在懇求之間是無形態(tài)的。從客戶端到效勞器的每個懇求都必需包括了解懇求所必需的信息。假如效勞器在懇求之間的任何工夫點重啟，客戶端不會獲得告訴。此外，無形態(tài)懇求可以由任何可用效勞器答復(fù)，這非常合適云核算之類的情況?？蛻舳丝梢跃彺鏀?shù)據(jù)以改良功能。

在效勞器端，使用順序形態(tài)和功用可以分為各類資本。資本是一個風(fēng)趣的概念實體，它向客戶端公開。資本的例子有：使用順序?qū)ο?、?shù)據(jù)庫記載、算法等等。每個資本都運用 URI (Universal Resource Identifier) 獲得一個專一的地址。一切資本都共享一致的界面，以便在客戶端和效勞器之間傳輸形態(tài)。運用的是規(guī)范的 HTTP 辦法，比方 GET、PUT、POST 和 DELETE。Hypermedia 是使用順序形態(tài)的引擎，資本透露表現(xiàn)經(jīng)過超鏈接互聯(lián)。

另一個主要的 REST 準則是分層系統(tǒng)，這透露表現(xiàn)組件無法調(diào)查它與之交互的中心層以外的組件。經(jīng)過將系統(tǒng)常識限制在單個層，可以限制整個系統(tǒng)的復(fù)雜性，促進了底層的自力性。

當(dāng) REST 架構(gòu)的約束前提作為一個全體使用時，將生成一個可以擴展到很多客戶端的使用順序。它還降低了客戶端和效勞器之間的交互推遲。一致界面簡化了整個系統(tǒng)架構(gòu)，改良了子系統(tǒng)之間交互的可見性。REST 簡化了客戶端和效勞器的完成。

RESTful的完成：RESTful Web 效勞與 RPC 款式的 Web 效勞

調(diào)查了什么是什么是REST，我們再看看RESTful的完成。比來，運用 RPC 款式架構(gòu)構(gòu)建的基于 SOAP 的 Web 效勞成為完成 SOA 最常用的辦法。RPC 款式的 Web 效勞客戶端將一個裝滿數(shù)據(jù)的信封（包羅辦法和參數(shù)信息）經(jīng)過 HTTP 發(fā)送到效勞器。效勞器翻開信封并運用傳入?yún)?shù)執(zhí)行指定的辦法。辦法的后果打包到一個信封并作為呼應(yīng)發(fā)還客戶端?？蛻舳耸盏胶魬?yīng)并翻開信封。每個對象都有本人共同的辦法以及僅公開一個 URI 的 RPC 款式 Web 效勞，URI 透露表現(xiàn)單個端點。它疏忽 HTTP 的大局部特征且僅支撐 POST 辦法。

因為輕量級以及經(jīng)過 HTTP 直接傳輸數(shù)據(jù)的特征，Web 效勞的 RESTful 辦法曾經(jīng)成為最經(jīng)常見的替代辦法?？梢赃\用各類言語（比方 Java 順序、Perl、Ruby、Python、PHP 和 Javascript[包羅 Ajax]）完成客戶端。RESTful Web 效勞凡間可以經(jīng)過主動客戶端或代表用戶的使用順序拜訪。然則，這種效勞的簡潔性讓用戶可以與之直接交互，運用它們的 Web 閱讀器構(gòu)建一個 GET URL 并讀取返回的內(nèi)容。

在 REST 款式的 Web 效勞中，每個資本都有一個地址。資本自身都是辦法挪用的目的，辦法列表對一切資本都是一樣的。這些辦法都是規(guī)范辦法，包羅 HTTP GET、POST、PUT、DELETE，還能夠包羅 HEADER 和 OPTIONS。

在 RPC 款式的架構(gòu)中，存眷點在于辦法，而在 REST 款式的架構(gòu)中，存眷點在于資本 —— 將運用規(guī)范辦法檢索并操作信息片段（運用透露表現(xiàn)的方式）。資本透露表現(xiàn)方式在透露表現(xiàn)方式中運用超鏈接互聯(lián)。

Leonard Richardson 和 Sam Ruby 在他們的著作 RESTful Web Services 中引入了術(shù)語 REST-RPC 夾雜架構(gòu)。REST-RPC 夾雜 Web 效勞不運用信封包裝辦法、參數(shù)和數(shù)據(jù)，而是直接經(jīng)過 HTTP 傳輸數(shù)據(jù)，這與 REST 款式的 Web 效勞是相似的。然則它不運用規(guī)范的 HTTP 辦法操作資本。它在 HTTP 懇求的 URI 局部存儲辦法信息。好幾個知名的 Web 效勞，比方 Yahoo 的 Flickr API 和 del.icio.us API 都運用這種夾雜架構(gòu)。

RESTful的完成：RESTful Web 效勞的 Java 框架

有兩個 Java 框架可以協(xié)助構(gòu)建 RESTful Web 效勞。erome Louvel 和 Dave Pawson 開拓的 Restlet（見 參考材料）是輕量級的。它完成針對各類 RESTful 系統(tǒng)的資本、透露表現(xiàn)、銜接器和媒體類型之類的概念，包羅 Web 效勞。在 Restlet 框架中，客戶端和效勞器都是組件。組件經(jīng)過銜接器相互通訊。該框架最主要的類是抽象類 Uniform 及其詳細的子類 Restlet，該類的子類是專用類，比方 Application、Filter、Finder、Router 和 Route。這些子類可以一同處置驗證、過濾、平安、數(shù)據(jù)轉(zhuǎn)換以及將傳入懇求路由到響應(yīng)資本等操作。Resource 類生成客戶端的透露表現(xiàn)方式。

JSR-311是 Sun Microsystems 的標(biāo)準，可認為開拓 RESTful Web 效勞界說一組 Java API。Jersey是對 JSR-311 的參考完成。

JSR-311 供應(yīng)一組注釋，相關(guān)類和接口都可以用來將 Java 對象作為 Web 資本展現(xiàn)。該標(biāo)準假定 HTTP 是底層收集和談。它運用注釋供應(yīng) URI 和響應(yīng)資本類之間的明晰映射，以及 HTTP 辦法與 Java 對象辦法之間的映射。API 支撐普遍的 HTTP 實體內(nèi)容類型，包羅 HTML、XML、JSON、GIF、JPG 等。它還將供應(yīng)所需的插件功用，以答應(yīng)運用規(guī)范辦法經(jīng)過使用順序添加其他類型。

RESTful的完成：構(gòu)建 RESTful Web 效勞的多層架構(gòu)

RESTful Web 效勞和動態(tài) Web 使用順序在很多方面都是相似的。有時它們供應(yīng)一樣或十分相似的數(shù)據(jù)和函數(shù)，雖然客戶端的品種分歧。例如，在線電子商務(wù)分類網(wǎng)站為用戶供應(yīng)一個閱讀器界面，用于查找、檢查和訂購產(chǎn)物。假如還供應(yīng) Web 效勞供公司、零售商甚至小我可以主動訂購產(chǎn)物，它將十分有效。與大局部動態(tài) Web 使用順序一樣，Web 效勞可以從多層架構(gòu)的存眷點別離中受益。營業(yè)邏輯和數(shù)據(jù)可以由主動客戶端和 GUI 客戶端共享。專一的分歧點在于客戶端的實質(zhì)和中心層的透露表現(xiàn)層。此外，從數(shù)據(jù)拜訪平分離營業(yè)邏輯可完成數(shù)據(jù)庫自力性，并為各類類型的數(shù)據(jù)存儲供應(yīng)插件才能。

圖 1 展現(xiàn)了主動化客戶端，包羅 Java 和各類言語編寫的劇本，這些言語包羅 Python、Perl、Ruby、PHP 或敕令行東西，比方 curl。在閱讀器中運轉(zhuǎn)且作為 RESTful Web 效勞消費者運轉(zhuǎn)的 Ajax、Flash、JavaFX、GWT、博客和 wiki 都屬于此列，由于它們都代表用戶以主動化款式運轉(zhuǎn)。主動化 Web 效勞客戶端在 Web 層向 Resource Request Handler 發(fā)送 HTTP 呼應(yīng)。客戶端的無形態(tài)懇求在頭部包括辦法信息，即 POST、GET、PUT 和 DELETE，這又將映射到 Resource Request Handler 中資本的響應(yīng)操作。每個懇求都包括一切必需的信息，包羅 Resource Request Handler 用來處置懇求的憑證。

從 Web 效勞客戶端收到懇求之后，Resource Request Handler 從營業(yè)邏輯層懇求效勞。Resource Request Handler 確定一切概念性的實體，系統(tǒng)將這些實體作為資本公開，并為每個資本分派一個專一的 URI。然則，概念性的實體在該層是不存在的。它們存在于營業(yè)邏輯層?？梢赃\用 Jersey 或其他框架（比方 Restlet）完成 Resource Request Handler，它應(yīng)該是輕量級的，將很多職責(zé)任務(wù)托付給營業(yè)層。

Ajax 和 RESTful Web 效勞實質(zhì)上是互為增補的。它們都可以應(yīng)用很多 Web 技能和規(guī)范，比方 HTML、JavaScript、閱讀器對象、XML/JSON 和 HTTP。當(dāng)然也不需求購置、裝置或裝備任何首要組件來支撐 Ajax 前端和 RESTful Web 效勞之間的交互。RESTful Web 效勞為 Ajax 供應(yīng)了十分簡略的 API 來處置效勞器上資本之間的交互。

圖 1 中的 Web 閱讀器客戶端作為 GUI 的前端，運用透露表現(xiàn)層中的 Browser Request Handler 生成的 HTML 供應(yīng)顯示功用。Browser Requester Handler 可以運用 MVC 模子（JSF、Struts 或 Spring 都是 Java 的例子）。它從閱讀器承受懇求，從營業(yè)邏輯層懇求效勞，生成透露表現(xiàn)并對閱讀器做出呼應(yīng)。透露表現(xiàn)供用戶在閱讀器中顯示運用。透露表現(xiàn)不只包括內(nèi)容，還包括顯示的屬性，比方 HTML 和 CSS。

<img class="fit-image" border="0" alt="多層 Web 使用順序情況圖" src="http://images.51cto.com/files/uploadimg/20090805/1546390.jpg" width="498" />

營業(yè)規(guī)矩可以集中到營業(yè)邏輯層，該層充任透露表現(xiàn)層和數(shù)據(jù)拜訪層之間的數(shù)據(jù)交流的中心層。數(shù)據(jù)以域?qū)ο蠡蛑祵ο蟮姆绞焦?yīng)給透露表現(xiàn)層。從營業(yè)邏輯層中解耦 Browser Request Handler 和 Resource Request Handler 有助于促進代碼重用，并能完成靈敏和可擴展的架構(gòu)。此外，因為未來可以運用新的 REST 和 MVC 框架，完成它們變得愈加輕易，無需重寫營業(yè)邏輯層。

數(shù)據(jù)拜訪層供應(yīng)與數(shù)據(jù)存儲層的交互，可以運用 DAO 設(shè)計形式或許對象-關(guān)系映射處理方案（如 Hibernate、OJB 或 iBATIS）完成。作為替代方案，營業(yè)層和數(shù)據(jù)拜訪層中的組件可以完成為 EJB 組件，并獲得 EJB 容器的支撐，該容器可認為組件生命周期供應(yīng)便當(dāng)，治理耐久性、事務(wù)和資本裝備。然則，這需求一個服從 Java EE 的使用效勞器（比方 JBoss），而且能夠無法處置 Tomcat。該層的效果在于針對分歧的數(shù)據(jù)存儲技能，從營業(yè)邏輯平分離數(shù)據(jù)拜訪代碼。數(shù)據(jù)拜訪層還可以作為銜接其他系統(tǒng)的集成點，可以成為其他 Web 效勞的客戶端。

數(shù)據(jù)存儲層包羅數(shù)據(jù)庫系統(tǒng)、LDAP 效勞器、文件系統(tǒng)和企業(yè)信息系統(tǒng)（包羅遺留系統(tǒng)、事務(wù)處置系統(tǒng)和企業(yè)資本規(guī)劃系統(tǒng)）。運用該架構(gòu)，您可以開端看到 RESTful Web 效勞的力氣，它可以靈敏地成為任何企業(yè)數(shù)據(jù)存儲的一致 API，然后向以用戶為中間的 Web 使用順序公開垂直數(shù)據(jù)，并主動化批量申報劇本。

什么是REST：完畢語

REST 描繪了一個架構(gòu)款式的互聯(lián)絡(luò)統(tǒng)（如 Web 使用順序）。REST 約束前提作為一個全體使用時，將生成一個簡略、可擴展、有用、平安、牢靠的架構(gòu)。因為它簡潔、輕量級以及經(jīng)過 HTTP 直接傳輸數(shù)據(jù)的特征，RESTful Web 效勞成為基于 SOAP 效勞的一個最有出路的替代方案。用于 web 效勞和動態(tài) Web 使用順序的多層架構(gòu)可以完成可重用性、簡略性、可擴展性和組件可呼應(yīng)性的明晰別離。Ajax 和 RESTful Web 效勞實質(zhì)上是互為增補的。開拓人員可以輕松運用 Ajax 和 RESTful Web 效勞一同創(chuàng)立豐厚的界面。