REST HATEOAS-客户端如何知道链接语义？

Question

想象一下，我有一个完全实现的REST API，它也提供了HATEOAS。

假设我浏览了根目录，除了自我链接之外，还返回了其他两个链接(例如，一个用于/users和一个用于/orders)。据我所知，HATEOAS消除了对带外信息的需求。客户应该如何知道users的含义？语义存储在哪里？

我知道这是一个愚蠢的问题，但我真的很想知道。

Answer 1

假设您刚刚发现了Twitter，并且是第一次使用它。在您的Web浏览器中，您会看到一列段落，其中有一堆链接散布在页面上。您知道有一种方法可以执行此操作，但是您不知 Prop 体可以使用哪些操作。您如何弄清楚它们是什么？

好吧，您查看链接并考虑其名称的含义。您立即根据约定认识到了一些内容:作为一名经验丰富的Web用户，您非常了解单击“主页”，“搜索”和“退出”链接意味着什么。

但是其他链接具有您无法识别的名称。 “转推”是做什么的？那颗小星星图标有什么作用？

基本上，您或任何人有两种方法可以解决此问题:

通过实验，也就是说，单击链接并查看发生了什么，然后从结果中得出每个链接的含义。

通过带外信息的一些来源，例如在线帮助，通过Google搜索找到的教程或坐在您旁边的 friend 解释了该站点的工作方式。

REST API相同。 (回想一下，REST旨在对Web启用与人类交互的方式进行建模。)

尽管原则上计算机(或API客户端开发人员)可以通过实验来推断链接关系的语义，但显然这是不切实际的。那离开

约定，例如基于the IANA 的list of standardized link relations及其含义。

带外信息，例如API文档。

REST的概念并没有什么矛盾，它要求客户端开发人员依靠API本身以外的东西来理解链接关系的含义。这是使用网站的人的标准做法，而使用网站的人就是REST模型。

REST所要做的就是消除了与API交互有关 机制的带外信息的需求。回到Twitter的例子，您可能不得不在某个时候向您解释“转推”链接的确切作用。但是您不必知道要键入以进行转发的特定URL，也不必知道您要操作的推文的ID号，甚至不必知道推文具有唯一ID的事实。 Web的设计意味着一旦您确定要单击哪个链接，就可以为您解决所有这些复杂性。

REST API也是如此。的确，在大多数情况下，只需告诉计算机或程序员每个链接关系的含义即可。但是一旦获得了这些信息，他们就可以浏览整个API，而无需了解有关如何将它们组合在一起的详细信息。