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