REST的使用，多从资源角度考虑设计，而我却以为不竟然，我以为可以同时从资源和RPC的角度考虑设计。
首先要明确的是RESTful是一种面向Sevrice和资源的架构类型，而不是标准，与此相对，它使用了如下的标准：
* HTTP
* URI
* XML/HTML/JSON/GIF/etc（Resource Representations）
注：这里的“资源”可以理解为，1、真实的资源（可以CRUD）；2、看作是Service API返回的结果（只能R）。
REST架构的具有如下特性：
统一接口：所有的资源通过统一的接口访问（HTTP GET, POST, PUT, DELETE)）
统一命名：REST系统中的资源(API)必须统一命名和规划，REST系统由使用URI命名的资源组成。REST最大的优势是提出了一个可以对资源和RPC统一命名的URI标准。这难能可贵。
交互形式: 主要以拉(pull)为基础的交互形式，通过长连接实现push。
可以缓冲：提升网络效能，可以将资源（响应）分为可缓存的和不可缓存的。
资源呈现：资源呈现（Resource Representation）允许有不同的表现的形式（text,xml,json,bin,gif,...）, 同一RESTful API可以取得不同表现形式的Resource。
分层组件：可以在客户和资源之间插入不同的中间组件来提升性能和安全等，如，代理服务，缓存服务，网关服务等。
无状态：本次连接和下一次到服务器的连接之间没有状态。这在在服务之间需要状态的时候是弊端。如果服务内的状态可以用长连接解决（如聊天服务）。
RESTful使用http方法（GET, PUT, DELETE, POST）来调用API或管理资源.
从RPC API的角度来看，这些方法的使用目标如下：
Http方法 使用目标
GET 可以缓冲的 resources
GET, PUT 可以缓冲和修改的 resources
GET, PUT, DELETE 可以缓冲，修改和删除的 resources
POST 不能缓冲的 resources
首先要明确的是RESTful是一种面向Sevrice和资源的架构类型，而不是标准，与此相对，它使用了如下的标准：
* HTTP
* URI
* XML/HTML/JSON/GIF/etc（Resource Representations）
注：这里的“资源”可以理解为，1、真实的资源（可以CRUD）；2、看作是Service API返回的结果（只能R）。
REST架构的具有如下特性：
统一接口：所有的资源通过统一的接口访问（HTTP GET, POST, PUT, DELETE)）
统一命名：REST系统中的资源(API)必须统一命名和规划，REST系统由使用URI命名的资源组成。REST最大的优势是提出了一个可以对资源和RPC统一命名的URI标准。这难能可贵。
交互形式: 主要以拉(pull)为基础的交互形式，通过长连接实现push。
可以缓冲：提升网络效能，可以将资源（响应）分为可缓存的和不可缓存的。
资源呈现：资源呈现（Resource Representation）允许有不同的表现的形式（text,xml,json,bin,gif,...）, 同一RESTful API可以取得不同表现形式的Resource。
分层组件：可以在客户和资源之间插入不同的中间组件来提升性能和安全等，如，代理服务，缓存服务，网关服务等。
无状态：本次连接和下一次到服务器的连接之间没有状态。这在在服务之间需要状态的时候是弊端。如果服务内的状态可以用长连接解决（如聊天服务）。
RESTful使用http方法（GET, PUT, DELETE, POST）来调用API或管理资源.
从RPC API的角度来看，这些方法的使用目标如下：
Http方法 使用目标
GET 可以缓冲的 resources
GET, PUT 可以缓冲和修改的 resources
GET, PUT, DELETE 可以缓冲，修改和删除的 resources
POST 不能缓冲的 resources
