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