REST 与旅行商问题的设计

最近，Mark Baker 在推特上对 Github 上的某个 Nokia REST API 项目发了条帖子：

尤其值得关注的是文中的这么一段话：

我们注意到的最大优点是，API 它本身就成为了描述 API 的文档

• 如果没有 HATEOAS（超媒体即应用状态引擎），开发者必需获取数据，查找文档，然后才能明白如何发送下一条请求。
• 有了 HATEOAS，开发者就能明白接下来能够做什么。

来自 CapGemini 的 Steve Jones 在他最近的一篇博客中专门对此进行了评论：

以上任何一条观点都让我忍不住要炮轰你。我是文档的忠实粉丝，也是设计的忠实粉丝。我所不敢苟同的是，有些家伙总把设计的过程看成一系列的抽象步骤，而把下一步当作唯一重要的事。

Steve 之前也提到过，他相信如今的 IT 界推崇技术而冷落思考，他表示这篇关于 Nokia 的文字在某种程度上再次印证了这一观点：思考及设计已死，或正在 IT 界消亡。他认为有些人不再重视设计的价值，并不断地削弱其在开发过程中的重要性。

让我们说清楚些，有着详细的文档非常重要。而以下两种情况都是糟糕的：

1. 必须等到其他人创建了应用之后，我才可以着手打造一个客户端。
2. 当前的文档看起来就像是“错综复杂的曲折通道”，你顶多只能看到下一步。

按照 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。

查看英文原文： REST and the Travelling Salesman Design