【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，以供开发者考虑和利用。