【IT168 資訊】Collaxa BPEL產品-後來成為Oracle SOA戰略核心的一部分-背後的關鍵人物之一，Edwin Khodabakchian，已經單獨致力於Feedly這一「將twitter和Google Reader編織成雜誌一般的體驗」的項目好幾年了。最近Edwin發布了一本關於構建基於JSON的Web服務最佳實踐的cookbook。當然這還在進行當中，但現有提供的指南包括了：
第一階段-定義一個簡單的資源/服務 | 選一個示例資源比如客戶信息，用JSON來對其建模。構建一個簡單的servlet，以PUT來創建一個新客戶，以GET基於客戶鍵值返回客戶信息，以DELETE刪除客戶，以POST更新客戶信息。保證PUT返回的是關於新創建資源URL的正確信息。在我們的案例中，我們有一個將JSON映射到Java模型的框架，使用Hibernate在MySQL資料庫中對這一模型作持久化存儲。這一階段的關鍵是，用JSON正確的表示，並且基本url要有簡單整潔的格式。
還有：
第三階段－加入驗證 | 修改你的服務實現為通過PUT和POST所收到的JSON資源加入一些數據驗證。學會如何使用HHTP錯誤代碼來定義和轉移異常信息。學會如何在客戶端處理這些異常。這一階段的關鍵是保證你知道現在的HTTP錯誤代碼，在適當的時候重用它們，並且在需要的時候創建符合於HTTP的新代碼。
現在正在著述中的有7個不同的階段，其範圍從我們提到的第一個，到認證，到生命周期。看到來自現實經驗的指南一直都是非常棒，而且Edwin試圖覆蓋到在過去毫無疑問曾給它帶來困難的問題，比如：
有很多庫可用以幫助你抽象XMLHTTPRequest。選擇一個可以跨瀏覽器的。選擇一個足夠透明，能讓你看到你所調用的GET,POST,PUT和DELETE操作的。或者：
為業務事件定義合適的粒度和合適的類型不是那麼容易。你也許需要幾次的迭代才能把它做好。我的建議是不要過度設計：儘量保持簡單並且出現新用例時進行重構。
對於REST許多其支持者認為是理所當然的方面 ，當然也作出了參考，比如：
第五階段-添加緩存 | Web基礎設施提供了豐富的緩存機制(最後修改信息，緩存持續期，eTag)。學習機制並看看你是否能利用它們來提升服務的性能與伸縮性。
Edwin同時還涉及了一些非常實踐的方案，這些方案也許乍一看是有背於REST/HTTP原則的：
一些伺服器不允許DELETE，這一種情況下你得學會如何用方法重寫來POST。
根據 Edwin的說法，他們正在考慮將其後端的一些基礎設施開源出來。在些之前 FriendFeed API 的文檔是可獲得的。隨著JSON+REST的逐漸流行，這必將是本有趣的cookbook，以供開發者考慮和利用。