RESTful API

URL定位資源，用HTTP動詞（GET,POST,DELETE,DETC）描述操作。

例如

1. REST描述的是在網絡中client和server的一種交互形式；REST本身不實用，實用的是如何設計 RESTful API（REST風格的網絡接口）；

2. Server提供的RESTful API中，URL中只使用名詞來指定資源，原則上不使用動詞。“資源”是REST架構或者說整個網絡處理的核心。比如：

http://api.qc.com/v1/newsfeed: 獲取某人的新鮮; 

http://api.qc.com/v1/friends: 獲取某人的好友列表;

http:
 
//api.qc.com/v1/profile: 獲取某人的詳細信息;

3. 用HTTP協議裏的動詞來實現資源的添加，修改，刪除等操作。
即通過HTTP動詞來實現資源的狀態扭轉：
GET    用來獲取資源，
POST  用來新建資源（也可以用於更新資源），
PUT    用來更新資源，
DELETE  用來刪除資源。

比如：
DELETE http://api.qc.com/v1/friends: 刪除某人的好友 （在http parameter指定好友id）
POST http://api.qc.com/v1/friends: 添加好友
UPDATE http://api.qc.com/v1/profile: 更新個人資料
 

圖解

Server的API如何設計才滿足RESTful要求?

客戶-服務器（Client-Server），提供服務的服務器和使用服務的客戶需要被隔離對待。

無狀態（Stateless），來自客戶的每一個請求必須包含服務器處理該請求所需的所有信息。換句話說，服務器端不能存儲來自某個客戶的某個請求中的信息，並在該客戶的其他請求中使用。

可緩存（Cachable），服務器必須讓客戶知道請求是否可以被緩存。（Ross：更詳細解釋請參考 理解本真的REST架構風格 以及 StackOverflow 的這個問題 中對緩存的解釋。）

分層系統（Layered System），服務器和客戶之間的通信必須被這樣標準化：允許服務器和客戶之間的中間層（Ross：代理，網關等）可以代替服務器對客戶的請求進行回應，而且這些對客戶來說不需要特別支持。

統一接口（Uniform Interface），客戶和服務器之間通信的方法必須是統一化的。（Ross：GET,POST,PUT.DELETE, etc）

支持按需代碼（Code
 
-On-Demand，可選），服務器可以提供一些代碼或者腳本（Ross：Javascrpt，flash，etc）並在客戶的運行環境中執行。這條準則是這些準則中唯一不必必須滿足的一條。（Ross：比如客戶可以在客戶端下載腳本生成密碼訪問服務器。）

例如

GET /zoos：列出所有動物園
POST /zoos：新建一個動物園
GET /zoos/ID：獲取某個指定動物園的信息
PUT /zoos/ID：更新某個指定動物園的信息（提供該動物園的全部信息）
PATCH /zoos/ID：更新某個指定動物園的信息（提供該動物園的部分信息）
DELETE /zoos/ID：刪除某個動物園
GET /zoos/ID/animals：列出某個指定動物園的所有動物
DELETE /zoos/ID/animals/ID：刪除某個指定動物園的指定動物

【API設計】RESTful API 設計指南