REST和HTTP協議有什么區別？

Question

什么是REST協議，它與HTTP協議有什么不同？

Answer 1

REST是協議的一種設計風格，它是由Roy Fielding在其博士論文中開發的，並正式化了HTTP / 1.0背后的方法，找到了適合的方法，然后利用對它的更結構化的理解來影響HTTP / 1.0的設計。 1.1。 因此，盡管在很多方面都是事后的事，但是REST是HTTP背后的設計風格。

菲爾丁的論文可以在http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm上找到，非常值得閱讀，也很易讀。 博士學位論文可能非常艱辛，但是如果沒有類似的計算機科學水平，那么這篇論文的描述就很好，並且對於我們中的人來說可讀性很好。 REST本身非常簡單，這很有幫助。 這是別人提出來之后顯而易見的事情之一。 （為此，它還封裝了許多舊的Web開發人員以一種簡單的方式以艱難的方式學習到的東西，這使得閱讀它對許多人來說都是一個重要的時刻！）。

其他應用程序級協議以及HTTP也可以使用REST，但是HTTP是經典示例。

因為HTTP使用REST，所以HTTP的所有使用都在使用REST系統。 將Web應用程序或服務描述為RESTful或非RESTful涉及到它是利用REST還是對其進行工作。

RESTful系統的經典示例是沒有cookie的“普通”網站（cookie並不總是與REST相反，但它們可以）：用戶通過單擊加載另一個頁面的鏈接或執行GET表單來更改客戶端狀態。帶來結果的查詢。 POST表單查詢可以更改服務器和客戶端狀態（服務器在POST的基礎上執行某些操作，然后發送描述新狀態的超文本文檔）。 URI描述資源，但是描述它的實體（文檔）可能會根據用戶喜歡的內容類型或語言而有所不同。 最后，瀏覽器始終可以通過PUT和DELETE來更新頁面本身，盡管這種情況從未很普遍，現在已經不那么普遍了。

使用HTTP的非RESTful系統的經典示例是將HTTP視為一種傳輸協議，並且每次請求都將數據POST發送到同一URI，然后以類似RPC的方式對其進行處理連接本身具有共享狀態。

RESTful計算機可讀（即不是瀏覽器中的網站，而是通過編程方式使用的某種東西）系統將通過GETURI獲取有關資源的信息，然后URI將返回描述狀態的文檔（例如，但不一定是XML）包括相關資源的URI（因此為超媒體）的URI，通過描述新狀態的PUTTING實體或刪除它們來更改其狀態，並通過POST執行其他操作。

主要優點是：

可擴展性：缺乏共享狀態使得系統的可擴展性大大提高（當我從遭受嚴重打擊的網站上刪除所有對會話狀態的使用時，這在我身上得到了充分證明，而我希望它會帶來一些額外的性能，甚至是更長的時間，像我這樣的時間反會話倡導者被刪除會話本來就很小的收獲所震撼，這甚至都不是我為什么刪除它們的原因！）

簡單性：REST比其他類似RPC的模型有多種簡單的方法，尤其是只有少數“動詞”是可行的，每種資源都可以合理地與其他資源隔離開來。 。

輕量級實體：更多的類似RPC的模型傾向於最終以兩種方式發送的實體中的大量數據只是為了反映類似RPC的模型。 不需要這個。 實際上，有時在給定情況下真正需要的只是一個簡單的純文本文檔，在這種情況下，使用REST，這就是我們需要發送的所有文檔（盡管這只是“最終結果”的情況，因為純文本文檔文字未鏈接到相關資源）。 另一個經典示例是請求獲取圖像文件，類似RPC的模型通常必須將其包裝為另一種格式，並可能以某種方式對其進行編碼以使其位於父格式內（例如，如果類似RPC的模型使用XML） ，則該圖片將需要使用base-64編碼或類似圖片，以適合有效的XML）。 RESTful模型只會將文件傳輸到瀏覽器，就像傳輸文件一樣。

人類可讀的結果：不一定是這樣，但是在結果相對易於閱讀的地方構建RESTful Web服務通常很容易，這有助於調試和開發無止境。 我什至已經建立了一個XSLT，意思是整個東西都可以被人類用作一個（相對粗糙的）網站，盡管它並不是主要供人類使用（實質上，XSLT充當了將其呈現給客戶的客戶端）。用戶，甚至沒有在規范中，只是為了簡化我自己的開發！）。

服務器和客戶端之間的綁定松動：導致以后的開發更容易，或者系統的托管方式發生了變化。 的確，如果您保留超文本模型，則可以更改整個結構，包括從單主機遷移到用於不同服務的多個主機，而根本無需更改客戶端代碼。

緩存：對於客戶端獲得有關資源狀態信息的GET操作，標准的HTTP緩存機制允許兩種聲明，即最早直到某個日期資源才有意義地改變（直到那時才需要查詢） ），或者自上次查詢以來沒有更改過（發送數百字節的標頭說明了這一點，而不是幾千字節的數據）。 性能的提高可能是巨大的（在某些情況下，它的性能足以將某件產品的性能從不實用的位置轉移到不再關注性能的位置）。

工具箱的可用性：因為它的工作相對簡單，所以如果您有Web服務器，則可以構建RESTful系統的服務器，並且如果您具有任何HTTP客戶端API（瀏覽器javascript中的XHR，.NET中的HttpWebRequest等），則可以構建一個RESTful系統的客戶端。

彈性：特別是，缺少共享狀態意味着客戶端可以在服務器不知情的情況下死亡並重新使用，甚至服務器也可以在客戶端不知情的情況下死亡並重新使用。 顯然，在此期間的通信將失敗，但是一旦服務器重新聯機，一切就可以照原樣繼續進行。 這也確實簡化了網絡服務器場的冗余和性能使用-每個服務器都像它是唯一的服務器一樣工作，並且它實際上只處理來自給定客戶端的部分請求也沒關系。

Answer 2

REST是一種利用HTTP協議的方法，而不是替代方法。

• http://en.wikipedia.org/wiki/Representational_State_Transfer

數據由URL唯一引用，並且可以使用HTTP操作（GET，PUT，POST，DELETE等）進行操作。 消息/響應支持多種mime類型，但是XML和JSON是最常見的。

例如，要讀取有關客戶的數據，您可以對URL http://www.example.com/customers/1使用HTTP get操作。 如果要刪除該客戶，只需對相同的URL使用HTTP刪除操作。

以下Java代碼演示了如何通過HTTP協議進行REST調用：

String uri =
    "http://www.example.com/customers/1";
URL url = new URL(uri);
HttpURLConnection connection =
    (HttpURLConnection) url.openConnection();
connection.setRequestMethod("GET");
connection.setRequestProperty("Accept", "application/xml");

JAXBContext jc = JAXBContext.newInstance(Customer.class);
InputStream xml = connection.getInputStream();
Customer customer =
    (Customer) jc.createUnmarshaller().unmarshal(xml);

connection.disconnect();

對於Java（JAX-RS）示例，請參見：

• http://bdoughan.blogspot.com/2010/08/creating-restful-web-service-part-45.html

Answer 3

REST不是協議，它是一種通用的體系結構，用於描述無狀態的緩存客戶端-服務器分布式媒體平台。 REST體系結構可以使用多種不同的通信協議來實現，盡管HTTP是迄今為止最常見的協議。

Answer 4

REST不是協議，它是公開應用程序的一種方式，通常是通過HTTP完成的。

例如，您要公開應用程序中執行getClientById的api
而不是創建一個URL

yourapi.com/getClientById?id=4
你可以做
yourapi.com/clients/id/4

由於您使用的是GET方法，這意味着您要獲取數據

您可以利用HTTP方法的優勢：GET / DELETE / PUT
yourapi.com/clients/id/4也可以處理刪除，如果您發送的是delete方法而不是GET，則意味着您想刪除記錄

Answer 5

所有的答案都很好。

我在此添加對REST及其如何使用HTTP的詳細描述。

REST =代表性狀態轉移

REST是一組規則，遵循這些規則可使您構建具有一組特定的期望約束的分布式應用程序。

它是無狀態的，這意味着在理想情況下，客戶端和服務器之間不應保持任何連接。

客戶端負責將其上下文傳遞給服務器，然后服務器可以存儲此上下文以處理客戶端的進一步請求。 例如，服務器維護的會話由客戶端傳遞的會話標識符標識。

無國籍的優勢：

1. Web服務可以分別處理每個方法調用。
2. Web服務不需要維護客戶端的先前交互。
3. 反過來，這簡化了應用程序設計。
4. HTTP本身是不同於TCP的無狀態協議，因此RESTful Web服務可與HTTP協議無縫地協同工作。

無國籍的缺點：

1. 需要將每個標題的形式增加一層，以保留客戶端的狀態。
2. 為了安全起見，我們可能需要在每個請求中添加標頭信息。

REST支持的HTTP方法：

GET： /string/someotherstring ：
它是冪等的（意味着多個調用每次應返回相同的結果），理想情況下每次調用應返回相同的結果

放：
像GET一樣。 冪等，用於更新資源。

POST：應包含網址和正文
用於創建資源。 理想情況下，多次通話應返回不同的結果，並應創建多種產品。

刪除：
用於刪除服務器上的資源。

頭：

HEAD方法與GET相同，除了服務器在響應中不得返回消息正文。 響應HEAD請求的HTTP頭中包含的元信息應該與響應GET請求發送的信息相同。

選項：

此方法允許客戶端確定與資源相關聯的選項和/或要求，或者服務器的功能，而無需暗示資源操作或啟動資源檢索。

HTTP響應

去這里獲得所有答復 。

以下是一些重要的方面：
200-好
3XX-客戶端和URL重定向所需的其他信息
400-錯誤的要求
401-未經授權的訪問
403-禁止
該請求有效，但是服務器拒絕操作。 用戶可能沒有資源的必要權限，或者可能需要某種帳戶。

404-找不到
找不到請求的資源，但將來可能可用。 客戶的后續請求是允許的。

405-不允許使用的方法請求的資源不支持請求方法。 例如，要求通過POST呈現數據的表單上的GET請求，或只讀資源上的PUT請求。

404-找不到請求
500-內部服務器故障
502-錯誤的網關錯誤