若谷学院
互联网公司技术架构分享

星巴克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,有兴趣的同学可以看看。

原文出自:https://blog.csdn.net/cenwenchu79/article/list/5

好烂呀没啥价值凑合看看还不错很精彩 (还没有人评分)
Loading...
本站文章来自互联网一线技术博客,若有侵权,请联系我们:若谷技术学院 » 星巴克REST案例的分析总结-放翁
关注若谷技术,获得个性化即时架构文章推送

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

全球互联网技术架构,前沿架构参考

联系我们博客/网站内容提交