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

Question

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

假设我浏览了根,除了自我链接之外,还返回了两个其他链接(例如一个for /users和one for /orders).据我所知,HATEOAS消除了对带外信息的需求.客户应该如何知道什么users意思？语义存储在哪里？

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

Answer 1

假设你刚刚发现Twitter并且第一次使用它.在Web浏览器中,您会看到一列段落,其中包含遍布页面的大量链接.你知道有办法对此做些什么,但你不知道具体的行动是什么.你怎么弄清楚它们是什么？

那么,你看看链接,并考虑他们的名字是什么意思.有些你根据惯例立即认出:作为一个有经验的网络用户,你很清楚点击"主页","搜索"和"退出"链接是什么意思.

但其他链接有你不认识的名字."转推"做什么？什么是小星星图标吗？

你或任何人都有两种方法可以解决这个问题:

1. 通过实验,也就是说,点击链接并查看发生的情况,然后从结果中获得每个链接的含义.

2. 通过一些带外信息来源,例如在线帮助,通过Google搜索找到的教程或坐在您旁边的朋友解释网站的工作原理.

REST API也是如此.(回想一下,REST旨在模拟Web实现与人类交互的方式.)

虽然原则上计算机(或API客户端开发人员)可以通过实验推断出链接关系的语义,但显然这是不切实际的.离开了

1. 公约,例如基于对IANA的标准化链接关系的列表和它们的含义.

2. 带外信息,例如API文档.

REST概念中没有任何不一致的地方要求客户端开发人员依赖API本身以外的东西来理解链接关系的含义.这是使用网站的人类的标准做法,使用网站的人是REST模型.

REST实现的目标是不再需要有关与API交互机制的带外信息.回到Twitter的例子,你可能不得不让某人在某个时候向你解释究竟是什么,"转发"链接.但是,您不必知道要输入转发的特定URL,或者您想要操作的推文的ID号,或者甚至是推文具有唯一ID 的事实.Web的设计意味着一旦您确定要单击哪个链接,就会为您解决所有这些复杂问题.

所以它是REST API.确实,在大多数情况下,计算机或程序员只需要被告知每个链接关系的含义.但是,一旦他们有信息,他们可以通过整个API,而无需知道什么浏览其他关于它是如何放在一起的细节.