今天收到InfoQ的推薦郵件，看了標題就很感興趣，花了一些時間一看，果然是很不錯的一個案例分析，同時也讓自己學到了不少。大致羅列一下看后的一些文章重點內容。案例地址：http://www.infoq.com/cn/articles/webber-rest-workflow
1.通過REST服務請求完成狀態(tài)遷移，同時合理利用OPTIONS來查看資源操作權限。
2.合理利用Http Heads來返回資源URI，以及通過ErrorCode來確定操作結果，并且作后處理。
3.通過返回內容指定后續(xù)流程資源定位以及操作來實現(xiàn)流程化。
4.通過Put報頭的兩種版本比較標示來防止并發(fā)修改。（其實也可以優(yōu)化來做查詢緩存的工作）
5.使用Atom協(xié)議來發(fā)布和管理資源（Atom是最適合REST風格服務的數據源格式定義）
6.URI模版的使用建議，慎用，如果確實能夠有把握抽象資源定位。
7.Auth可以通過輕量級Http Head中的Authentication或者WS-*的方式來實現(xiàn)。（也可以通過https實現(xiàn)）
總的來說，其實整個案例分析下來以后，可以發(fā)現(xiàn)如果要使得服務流程化，那么前提就是數據交互格式統(tǒng)一（XML，Atom），然后利用Http協(xié)議作為服務協(xié)議而非承載協(xié)議，利用已有的操作約定，報文頭部標示和返回的錯誤碼來完成資源狀態(tài)遷移的工作，同時通過在返回內容中嵌入流程化內容，使得整個流程可以貫穿。（這里還是簡單的流程串聯(lián)，其實如果在流程規(guī)則協(xié)議中增加復雜的邏輯定義，則可以實現(xiàn)更為強大的Web workflow）。
但對于Open API或者類似的REST流程化業(yè)務來說，安全其實還是最大的挑戰(zhàn)，特別是在對資源的訪問控制權限上。當然可以類似于WS-Security提出一套較為安全成熟的方案，但是性能和使用簡易性則會大打折扣，也失去了REST本身的優(yōu)勢。