超文字傳輸協議是網路應用基本，當你傳輸文件或者傳送ajax請求的時候都會用到。但是對於一般的web開發者來說HTTP協議並不熟悉。這篇文章會介紹一些HTTP、REST的基本原理，然後你可以用這些構建一些跨系統跨平臺的介面。

為什麼是REST

REST是獨立系統間一種簡單的通訊方法。它從2005年開始流行，用來構建一一些像Twitter API這樣的應用。 因為REST允許以最小的開銷為不同的系統提供服務。從理論上來說，REST並不依附於網路，但是REST總是可以作為HTTP的一種補充，所以他可以用在任何HTTP可用的地方。

另一種辦法是在HTTP之上再建立一個協議。需要基於XML語法，典型的例子就是SOAP。你需要學習一些全新的東西，卻沒有發揮HTTP的威力。REST是HTTP驅動的，並且完全發揮了HTTP的能力，所以這也是學習HTTP的最佳實踐。

我們會先做一個概述，然後深入到HTTP的每個部分：URL，HTTP請求，狀態碼。我們也會展示如何在REST使用它們。我們會通過一個公司客戶與資料的應用來講解。

HTTP

HTTP是網路上允許傳送和接收文件的一個協議。所謂協議就是決定哪些資訊是可以交換的、哪些資訊是可以響應給其他人的一系列規則。另外一個常見的協議就是POP3，這個協議可以將你的郵件儲存在硬碟上。

在HTTP中，有兩種角色：服務端和客戶端。一般總是客戶端發起請求，然後服務端做出響應。HTTP是基於文字的，雖然訊息體內可能包含其他型別的內容。使用文字形式很便於展示和交換。

HTTP訊息由訊息頭和訊息內容構成。 訊息內容可以為空，他包含在頭部指令指揮下的你要傳遞給其他人的訊息內容。 訊息頭包含元資料，比如編碼資訊，在一次請求中也包含了重要的HTTP方法。在REST下，你經常發現頭資料比訊息內容還重要。

檢測HTTP請求

如果你使用Firefox的Firebug，那麼你點選網路標籤，然後啟用，這樣你在瀏覽的時候就能看見請求了。另一個可以檢視HTTP請求的辦法就是使用客戶端，比如cURL。

安裝cURL之後，鍵入下面的命令：
curl -v google.com
他會顯示完整的HTTP請求，請求前面會有<，響應則以>開始。

URLs

URL是用來區別你想要操作的物件的。我們可以認為每一個URL是一個資源。事實上，一個頁面就是一種資源。從我們的示例出發，我們管理著公司的客戶：

/clients

當連結為：

/clients/jim

的時候，就會鑑別出我們的客戶，架設他是唯一一個叫jim的。

在這些例子中，我們一般不包括主機的URL地址，但是主機域名是確定這個url是網路上的唯一資源的重要的標識。主機地址一般與資源地址在訊息頭裡是分離的:

1
2

GET /clientes/jim HTTP/1.1
Host:example.com

下面的這個就不是REST風格的：
/clients/add
這是因為他用一個連結來描述一個動作。這是區別REST系統和其他非REST系統的基本點。

最後，URL必須根據需要精確設計。設計的時候URL不應該是需要資料才能確定的。

但是怎麼區別每個動作呢，比如你想發起一個新請求而不是重新請求，這就該要提到HTTP動作了。

HTTP動作

每一個請求在訊息頭都有確定的動作。在訊息頭的第一個全大寫詞中表示。比如：
GET / HTTP/1.1
表示使用的是GET方法，再比如：
DELETE /clients/anne HTTP/1.1
表示使用了DELETE方法。

HTTP方法用來告訴伺服器根據URL來做什麼，一些附加資訊可以寫在訊息體內。在cURL中可以使用-d引數來新增資料。

如果你使用過HTTP表單，那麼你肯定對GET和POST方法很熟悉。其實還有很多HTTP方法。可以用來生成REST API的方法有GET,POST,PUT,DELETE。其他的方法也有用比如HEAD和OPTIONS，但是很少用到。

GET

GET方法是最簡單的HTTP請求方法，當你點選一個連結，或者在位址列輸入一個地址的時候就會觸發。他把客戶端的資料通過URL傳遞給服務端。使用GET方法時候，資料在服務端是不能被修改的。從這個角度來說GET請求是隻讀的，當然，一旦資料到了服務端，那麼想做什麼都是自由的。

PUT

PUT請求可以用來通過URL建立或者更新資源。例如：
PUT /client/robin
可能會在服務端建立一個robin的客戶。你會發現，在REST中，後端實現是完全被遮蔽的，這條請求中不會告訴服務端怎麼去建立這個客戶，只是告訴他要建立。這樣你就可以在需要的時候很容易的升級後端程式。PUT請求將需要修改的資料儲存在訊息體內。在cURL中，你可以新增-d引數。
curl -v -X PUT -d “some text”

DELETE

DELETE動作與PUT相反，用來刪除資源。

POST

當你對服務端需要進行重複請求的時候可以使用POST方法，另外，POST請求會引起服務端對你所POST的URL的訊息體的資料的處理。

POST /clients/
不會請求在clients的資源，但是可以修改。比如服務端可以自己新增一個客戶的ID。

PUT請求可以很容易的替代POST請求，反之亦然。有的系統只使用一個，有的使用PUT來建立操作，使用POST修改操作。

有些時候POST請求會觸發服務端的一些操作，而這寫操作不只是簡單的建立、修改、刪除。當然這在REST中有點超出範圍了，在我們的例子中，會一直使用PUT。

HTTP方法分類

安全和不安全的方法

安全的方法是指那些不修改資源的。上面列出的四個方法中，只有GET方法是安全的。其他都會修改資源。

冪等方法(Idempotent Methods)

這寫方法無論重複多少次，都返回相同的結果，他們有GET PUT DELETE。唯一一個不是冪等方法的就是POST。PUT和DELETE方法被歸類為冪等方法有些奇怪，然而，這也是很好解釋的：重複傳送一個訊息體相同的PUT方法，他只會對同樣的資源做同樣的處理，所以還是沒變。同樣，刪除就更好理解了。不論你執行多少次PUT和DELETE，結果都是一樣的。

需要注意的是，是你來決定這些方法之後做什麼操作。對於建改刪沒有固定的實現，你必須自己根據特定的環境做特定的處理。

綜述

我們可以總結為：服務端與客戶端通過URL來交換資訊。

我們認為請求和響應都包含資源的載體。所謂載體，就是指資訊按照一定的格式表現出來。訊息頭和訊息體都是載體的一部分。

HTTP的訊息頭，包括一些元資訊，都是HTTP規範裡定義過的。必須都是純文字的而且有一定的格式要求。

訊息體的內容可以使任何格式的，這也是HTTP請求的閃光點。如你所知的你可以傳送文字、圖片、視訊等等。通過不同的元資訊或者URL，你可以為一個資源請求不同的載體。比如，你可以為瀏覽器傳送一個網頁，為其他應用傳送JSON格式的資料。

HTTP的響應必須在訊息體內明示，比如：
Conrtent/Type:application/json

為了簡單起見，我們的示例程式使用JSON來傳輸資料。但是一個好的架構應該可以很輕鬆的為不同的請求返回不同格式的資料。