星巴克REST案例分析读后感

     今天收到InfoQ的推荐邮件，看了标题就很感兴趣，花了一些时间一看，果然是很不错的一个案例分析，同时也让自己学到了不少。大致罗列一下看后的一些文章重点内容。案例地址：http://www.infoq.com/cn/articles/webber-rest-workflow

    1.通过REST服务请求完成状态迁移，同时合理利用OPTIONS来查看资源操作权限。

    2.合理利用Http Heads来返回资源URI，以及通过ErrorCode来确定操作结果，并且作后处理。

    3.通过返回内容指定后续流程资源定位以及操作来实现流程化。

    4.通过Put报头的两种版本比较标示来防止并发修改。（其实也可以优化来做查询缓存的工作）

    5.使用Atom协议来发布和管理资源（Atom是最适合REST风格服务的数据源格式定义）

    6.URI模版的使用建议，慎用，如果确实能够有把握抽象资源定位。

    7.Auth可以通过轻量级Http Head中的Authentication或者WS-*的方式来实现。（也可以通过https实现）

    总的来说，其实整个案例分析下来以后，可以发现如果要使得服务流程化，那么前提就是数据交互格式统一（XML，Atom），然后利用Http协议作为服务协议而非承载协议，利用已有的操作约定，报文头部标示和返回的错误码来完成资源状态迁移的工作，同时通过在返回内容中嵌入流程化内容，使得整个流程可以贯穿。（这里还是简单的流程串联，其实如果在流程规则协议中增加复杂的逻辑定义，则可以实现更为强大的Web workflow）。

    但对于Open API或者类似的REST流程化业务来说，安全其实还是最大的挑战，特别是在对资源的访问控制权限上。当然可以类似于WS-Security提出一套较为安全成熟的方案，但是性能和使用简易性则会大打折扣，也失去了REST本身的优势。

    做一下广告：http://www.blogjava.net/cenwenchu/archive/2008/12/10/245414.html 是我下周一将会作的一次关于Open API的内部培训的ppt，有兴趣的同学可以看看。