最近,Mark Baker 在推特上对 Github 上的某个 Nokia REST API 项目发了条帖子:
尤其值得关注的是文中的这么一段话:
我们注意到的最大优点是,API 它本身就成为了描述 API 的文档
- 如果没有 HATEOAS(超媒体即应用状态引擎),开发者必需获取数据,查找文档,然后才能明白如何发送下一条请求。
- 有了 HATEOAS,开发者就能明白接下来能够做什么。
来自 CapGemini 的 Steve Jones 在他最近的一篇博客中专门对此进行了评论:
以上任何一条观点都让我忍不住要炮轰你。我是文档的忠实粉丝,也是设计的忠实粉丝。我所不敢苟同的是,有些家伙总把设计的过程看成一系列的抽象步骤,而把下一步当作唯一重要的事。
Steve 之前也提到过,他相信如今的 IT 界推崇技术而冷落思考,他表示这篇关于 Nokia 的文字在某种程度上再次印证了这一观点:思考及设计已死,或正在 IT 界消亡。他认为有些人不再重视设计的价值,并不断地削弱其在开发过程中的重要性。
让我们说清楚些,有着详细的文档非常重要。而以下两种情况都是糟糕的:
- 必须等到其他人创建了应用之后,我才可以着手打造一个客户端。
- 当前的文档看起来就像是“错综复杂的曲折通道”,你顶多只能看到下一步。
按照 Steve 所说,当前的趋势是以代码为核心,而非以设计为核心,尤其体现于 REST 和 HATEOAS 方面。如果服务能提供文档化的 API,那就使得设计者不仅能够设定他们所想要的结果,而且还能够明确他们如何完成目标,这一点在服务的实现还没有完成之前体现得尤其明显。Steve 表示,按照之前 Mark 所说的 REST 工作方式,设计者将不得不在 API、代码和伪设计间不断切换,无论如何,这至少是一种不太有效率的方式。基于他在当前各公司里的所见所闻,他表示当前的趋势正在妨碍 IT 界的发展,并影响到了 REST 及其它解决方案的维护。
这是我对 REST 的抗议之一,即在功能实现前缺乏事先设计工作。如果我的客户端和服务端是各自独立的团队,我可不希望开展一个瀑布式的项目,先完成服务端,再开始客户端工作。如果参与双方是独立的公司,我希望能够看出问题出自哪一方,而不是进入这种恶性循环:“你要的东西就在响应里”或是“这东西怎么和昨天不一样”,诸如此类。换句话说,我希望看到大家能计划好结果的呈现。
不过,Steve 也并不反对使用 REST 作为实现方式。他只是相信当前他所看到的方式(例如 Nokia API)无助于重要的设计阶段,并且会最终引导至一种旅行商问题的解决方式:
如果我不清楚完成整个旅行的路线,而只是基于我当前所处的位置所能看到的最快路线作出决定,那我实际上并没有看到一个贯穿始终的有效实现,而只是为下一步的实现选择了最简单的方式。
在 Steve 的帖子下有如下一条留言,为这次讨论加入了一些观点:
我也在公开的 API 中看到了类似的现象发生,无论是 REST 或是类库等等。开发者已经普遍拥护以极少的通信实现功能的这种(非常好的)观点。但事情在不断的迭代中出现了变化,出于某些原因,开发者认为事先的设计并不重要,甚至是有害的。对于 API 之下的底层工作,选择渐进演化的设计是能够接受的,但公开的 API 应该从一开始就是比较准确的。它可以以某些方式进行演化(例如扩展),但对它的重构会导致用户不该有的负担。
Steve 也呼吁 REST 应该有一个文档化 RESTful API 的标准实践,同时最好能提供一个测试环境。另一位留言者则指出,不要仅仅依赖于HATEOAS。
评论