Restful 指的是架构的约束条件和原则，即一种设计思想。
如果一种架构符合 Restful 原则，就称它为 Restful 架构。
资源 Resources：
网络上的一个实体，如一个文件，一种服务。每个资源对应一个特定的 URI。表现层 Representation：
资源具体的呈现形式，如 JSON，XML等等。
URI 只代码资源的位置，资源具体的呈现形式应该在 HTTP 请求的 Header 中用 Accept 和 Content-Type。状态转化 State Transfer：
HTTP 协议是无状态的，所有的状态都保存在服务器端。如果客户端想要操作服务器端，必须通过某些手段，即 HTTP 动词，从而让服务的发生状态转化 State Transfer。
HTTP 协议的 4 个动词
- GET：获取资源
- POST：新建资源或者更新资源
- PUT：更新资源
- DELETE：删除资源
Restful 架构设计的几个误区
URI 中包含动词。例如 /blog/show/123
资源表示一种实现，URI 应该是名词，不应该包含动词。
动词应该放在 HTTP 协议中。
正确写法：GET /blog/123，HTTP 协议中使用动词 GET。
如果某些动作是 HTTP 动词表示不了的，应该把动作做成一种资源。
例如：POST /transaction
REST 关注于暴露数据。它减少了客户端／服务端的耦合程度，经常用于公共 HTTP API 接口设计。REST 使用更通常与规范化的方法来通过 URI 暴露资源，通过 header 来表述并通过 GET、POST、PUT、DELETE 和 PATCH 这些动作来进行操作。因为无状态的特性，REST 易于横向扩展和隔离。
REST缺点：
- 由于 REST 将重点放在暴露数据和资源，所以当资源不是自然组织的或者结构复杂的时候它可能无法很好的适应。举个例子，返回过去一小时中与特定事件集匹配的更新记录这种操作就很难表示为路径。使用 REST，可能会使用 URI 路径，查询参数和可能的请求体来实现。
- REST 一般依赖几个动作（GET、POST、PUT、DELETE 和 PATCH），但有时候仅仅这些没法满足你的需要。举个例子，将过期的文档移动到归档文件夹里去，这样的操作可能没法简单的用上面这几个动词表达。
- 为了渲染单个页面，获取被嵌套在层级结构中的复杂资源需要客户端，服务器之间多次往返通信。例如，获取博客内容及其关联评论。对于使用不确定网络环境的移动应用来说，这些多次往返通信是非常麻烦的。
- 随着时间的推移，更多的字段可能会被添加到 API 响应中，较旧的客户端将会接收到所有新的数据字段，即使是那些它们不需要的字段，结果它会增加负载大小并引起更大的延迟。
RPC 与 REST 比较
RPC 与 REST 比较
JAX-RS
基于 Restful 的 Web Service 的一组 Java API。
Spring 中集成 Restful
@RequestMapping("/rest")
public class MyTestEndpoint {
// URI 表示为 /rest/test
@RequestMapping(value"test", method=RequestMethod.POST)
public String test(@RequestParam(value="username") String username,
@RequestParam(value="password") String password) {
...
return SUCCESS;
}
}
<bean id="serviceEndpoint" class="JAXRSServiceEndpoint">
<property name="serviceBeans">
<list>
<bean class="MyTestEndpoint" />
<list>
</property>
</bean>
