from: http://www.infoq.com/cn/articles/webber-rest-workflow
infoq上这篇文章很通俗的介绍了一个用rest接口的SOA系统，比较值得一看，其中还可以学到很多http协议的相关知识。
个人把有价值的内容摘抄了一下：
1. 部分更新
尽管部分更新（partial updates）属于REST社区里比较难懂的理念争论之一，但这里我们采取一种实用的做法，我们假定：增加一杯浓咖啡的请求，是在现有资源状态的上下文中被处理的。因此，我们没必要在网络上传送整个资源表示，我们只要传送变化的部分即可。
2. 对于更新需要注意的事项（幂等），以及实现方法（序列号或者是数据版本号“ETag”）
用Web进行一致的状态更新可以采取很多种模式。HTTP PUT是幂等的（idempotent），这样我们在进行状态更新时就用不着处理一些复杂事务了，不过仍有一些选择需要我们决定。下面是正确进行状态更新的一些方法：
a. 通过发送
OPTIONS请求，查询服务是否接受PUT操作。这一步是可选的。它可以告知客户端，此刻服务器允许对该资源做哪些操作，不过这无法保证服务器将永远支持那些操作。b. 使用
If-Unmodified-Since或If-Match报头，以避免服务器执行不必要的PUT操作。假如PUT后来失败了，那么你会得到412 Precondition Failed。此方法要求：要么资源是缓慢更新的，要么支持ETag；对于前者就用If-Unmodified-Since，对于后者就用If-Match。c. 立即用
PUT操作提交更新，并应付可能出现的409 Conflict响应。就算我们使用了（1）和（2），我们可能仍得应付这些响应，因为我们的“哨兵”和检查本质上都是乐观的。关于检测和处理不一致的更新，W3C有一个非规范性文档，该文档推荐采用ETag。ETags也是我们推荐采用的方法。
3. 微格式（microformat）是一个比较好玩的地方，有点类似c/s协议中的重定向协议，但是更强大！
状态机和工作流不是像WS-BPEL或WS-CDL那样事先描述好的，而是在你 经历各个状态的过程中逐步得到描述的。不过，一旦你的想明白了，你就会发现，跟随链接（following links）这种方式使得我们可以在应用的各种状态下向前推进。每次状态迁移时，当前资源的表示里都包含了指向可能的下一状态的链接以及它们所代表的状 态