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