restful架構，就是目前最流行的一種網際網路軟體架構。它結構清晰、符合标準、易于了解、擴充友善，是以正得到越來越多網站的采用。
rest改善了使用者接口跨多個平台的可移植性，并且通過簡化伺服器元件，改善了系統的可伸縮性。最為關鍵的是通過分離使用者接口和資料存儲這兩個關注點，使得不同使用者終端享受相同資料成為了可能。
1. 無狀态性
無狀态性是在客戶－伺服器限制的基礎上添加的又一層規範。他要求通信必須在本質上是無狀态的，即從客戶到伺服器的每個request都必須包含了解 該request所必須的所有資訊。這個規範改善了系統的可見性（無狀态性使得用戶端和伺服器端不必儲存對方的詳細資訊，伺服器隻需要處理目前 request，而不必了解所有的request曆史），可靠性（無狀态性減少了伺服器從局部錯誤中恢複的任務量），可伸縮性（無狀态性使得伺服器端可以 很容易的釋放資源，因為伺服器端不必在多個request中儲存狀态）。同時，這種規範的缺點也是顯而易見得，由于不能将狀态資料儲存在伺服器上的共享上 下文中，是以增加了在一系列request中發送重複資料的開銷，嚴重的降低了效率。
2. 緩存
為了改善無狀态性帶來的網絡的低效性，我們填加了緩存限制。緩存限制允許隐式或顯式地标記一個response中的資料，這樣就賦予了用戶端緩存 response資料的功能，這樣就可以為以後的request共用緩存的資料，部分或全部的消除一部分互動，增加了網絡的效率。但是用于用戶端緩存了信 息，也就同時增加了用戶端與伺服器資料不一緻的可能，進而降低了可靠性。
3. 統一接口
rest架構風格的核心特征就是強調元件之間有一個統一的接口，這表現在rest世界裡，網絡上所有的事物都被抽象為資源，而rest就是通過通用 的連結器接口對資源進行操作。這樣設計的好處是保證系統提供的服務都是解耦的，極大的簡化了系統，進而改善了系統的互動性和可重用性。并且rest針對 web的常見情況做了優化，使得rest接口被設計為可以高效的轉移大粒度的超媒體資料，這也就導緻了rest接口對其它的架構并不是最優的。
4. 分層系統
分層系統規則的加入提高了各種層次之間的獨立性，為整個系統的複雜性設定了邊界，通過封裝遺留的服務，使新的伺服器免受遺留用戶端的影響，這也就提高了系統的可伸縮性。
5. 按需代碼
rest允許對用戶端功能進行擴充。比如，通過下載下傳并執行applet或腳本形式的代碼，來擴充用戶端功能。但這在改善系統可擴充性的同時，也降低了可見性。是以它隻是rest的一個可選的限制。
每個資源都有對應的uri，不同的http method對應的對資源不同的操作，get（讀取資源資訊）、post（添加資源）、put（更新資源資訊）、delete（删除資源）。幾乎所有的計算機語言都可以通過http協定同rest伺服器通信。
get /tickets # 擷取ticket清單
get /tickets/12 # 檢視某個具體的ticket
post /tickets # 建立一個ticket
put /tickets/12 # 更新ticket 12.
delete /tickets/12 #删除ticekt 12
如果關系依托于另外一個資源，restful原則提供了很好的指導原則。讓我們來看一個例子。supportfu的一個ticket包含許多消息（message）。這些消息邏輯上與/tickets接入點的映射關系如下：
get /tickets/12/messages - 擷取ticket #12下的消息清單
get /tickets/12/messages/5 - 擷取ticket #12下的編号為5的消息
post /tickets/12/messages - 為ticket #12建立一個新消息
put /tickets/12/messages/5 - 更新ticket #12下的編号為5的消息
patch /tickets/12/messages/5 - 部分更新ticket #12下的編号為5的消息
delete /tickets/12/messages/5 - 删除ticket #12下的編号為5的消息
get /tickets?sort=-priority - 擷取票據清單，按優先級字段降序排序
場景：
a:http://www.nowamagic.net/articles
b:http://www.nowamagic.net/articles/{id}
a網址：get方法：顯示全部使用者資訊；同時有個post方法，用來添加使用者；
b網址：get方法：顯示目前使用者資訊；put方法：更新使用者資訊；delete方法：删除該使用者資訊。
注意restclient form的enctype屬性x-www-form-urlencoded，form-data 是檔案上傳
最常見的一種設計錯誤，就是uri包含動詞 因為"資源"表示一種實體，是以應該是名詞，uri不應該有動詞，動詞應該放在http協定中。舉例來說，某個uri是/posts/show/1，其中show是動詞，這個uri就設計錯了，正确的寫法應該是/posts/1，然後用get方法表示show。
如果某些動作是http動詞表示不了的，你就應該把動作做成一種資源。比如網上彙款，從賬戶1向賬戶2彙款500元，錯誤的uri是：
post/accounts/1/transfer/500/to/2
正确的寫法是把動詞transfer改成名詞transaction，資源不能是動詞，但是可以是一種服務：
post/transaction
http/1.1
host: 127.0.0.1
from=1&to=2&amount=500.00
另一個設計誤區，就是在uri中加入版本号：
http://www.example.com/app/1.0/foo
http://www.example.com/app/1.1/foo
因為不同的版本，可以了解成同一種資源的不同表現形式，是以應該采用同一個uri。版本号可以在http請求頭資訊的accept字段中進行區分
accept: vnd.example-com.foo+json; version=1.0
accept: vnd.example-com.foo+json; version=1.1
二、處理傳回值。 傳回值要麼是json格式，要麼是xml格式。
php如何擷取rest的http的請求put或delete的資料
$method = $_server['request_method']; //請求
$rawbody = file_get_contents("php://input");
$form = json_decode($rawbody, true); //資料
//注意：jquery其它http請求方法，如put和delete 也可以使用，但僅部分浏覽器支援。
//getone or delete
$.ajax({
url:'/api/work/1',
type:"get", //delete
success:function(data) {
console.log(data);
},
error:function (xhr, ajaxoptions, thrownerror){
console.log(xhr.responsetext);
}
});
var postdata = {
"title": "title31",
"author_id": "31",
"content": "content31",
"create_time": "2013-08-20 09:23:14"
};
//create or update
url:'/api/work',
data:json.stringify(postdata)
type:"post", //put
console.log(data);
console.log(xhr.responsetext);
});
sfsd