REST Service 基础

1. 代表性状态传输（Representational State Transfer，REST）。

2. REST 要求开发人员显式地使用 HTTP 方法，并且使用方式与协议定义一致。 这个基本 REST 设计原则建立了创建、读取、更新和删除（create, read, update, and delete，CRUD）操作与 HTTP 方法之间的一对一映射。 

按照HTTP协议的规定，GET方法时安全的且幂等的，POST方法是既不安全也不幂等的（可以用来作为所有写操作的通配方法）， PUT/DELETE方式都是不安全但是幂等的。将对资源的操作合理映射到这四个方法上面，既不过度使用某周方法（例如过度使用GET方法和POST方法），也不添加过多的操作以至于HTTP的四个方法都不够用。

根据此映射：

• 若要在服务器上创建资源，应该使用 POST 方法。
• 若要检索某个资源，应该使用 GET 方法。
• 若要更改资源状态或对其进行更新，应该使用 PUT 方法。
• 若要删除某个资源，应该使用 DELETE 方法。

3. 不要将 HTTP 方法用于非预期用途，例如， 不要将Get用于创建artifact.

GET 的其他问题在于，为了触发数据库中的记录的删除、修改或添加，或者以某种方式更改服务器端状态，它请求 Web 缓存工具（爬网程序）和搜索引擎简单地通过对某个链接进行爬网处理，从而意外地做出服务器端更改。 克服此常见问题的简单方法是将请求 URI 上的参数名称和值转移到 XML 标记中。

4. 一般原则， 在URI中使用名词。

i.e.  addUser - > Post /users

       updateUser -> PUT /users/michael

5. 无状态。REST Web 服务需要发送完整、独立的请求；也就是说，发送的请求包括所有需要满足的数据，以便中间服务器中的组件能够进行转发、路由和负载平衡，而不需要在请求之间在本地保存任何状态。

互联网通信协议HTTP协议，是一个无状态协议。这意味着，所有的状态都保存在服务器端。因此，如果客户端想要操作服务器，必须通过某种手段，让服务器端发生"状态转化"（State Transfer）。而这种转化是建立在表现层之上的，所以就是"表现层状态转化"。

i.e.  

在有状态的情况下请求

GET /resources/getNextPage?pagesize=10

<current page> 1 < /current page>

<last data> 10</last data>

我跟人的理解若果有30条数据， 那么page1 包含 1- 10， page2包含11-20， 在有状态的情况下， 如果在请求之前删除数据1， 2，在getNextPage请求后会返回页面11 - 10.

但是在无状态的情况下会getNextPage会返回地13 - 22条数据。

RESTful架构对于state的两个不同的解释: 应用状态(Application State)和资源状态(Resource State)。

• 应用状态：指的是与某一特定请求相关的状态信息
• 资源状态：则反映了某一存储在服务器端资源在某一时刻的特定状态，该状态不会因为用户请求而改变，任何用户在同一时刻对该资源的请求都会获得这一状态的表现（Representation）。

REST Web 服务 URI 的直观性应该达到很容易猜测的程度。 将 URI 看作是自身配备文档说明的接口，开发人员只需很少（如果有的话）的解释或参考资料即可了解它指向什么，并获得相关的资源。

在考虑基于 REST 的 Web 服务的 URI 结构时，需要指出的一些附加指导原则包括：

• 隐藏服务器端脚本技术文件扩展名（.jsp、.php、.asp）——如果有的话，以便您能够移植到其他脚本技术而不用更改 URI。
• 将所有内容保持小写。
• 将空格替换为连字符或下划线（其中一种或另一种）。
• 尽可能多地避免查询字符串。
• 如果请求 URI 用于部分路径，与使用 404 Not Found 代码不同，应该始终提供缺省页面或资源作为响应。

下一篇 ： REST Service 基础 A further step.

Reference：

http://www.ibm.com/developerworks/webservices/library/ws-restful/

http://developer.51cto.com/art/200906/129424.htm

http://www.myexception.cn/software-architecture-design/1293211.html