连通性HATEOAS

Question

据说，在一个定义良好的RESTful系统中，客户端只需知道根URI或几个众所周知的URI，客户端就会通过这些初始URI发现所有其他链接。我确实理解这种方法的好处（解耦客户端），但对我来说不利的是客户端每次尝试访问时都需要发现链接，即给定以下资源层次结构：

/collection1
collection1
  |-sub1
    |-sub1sub1
 |-sub1sub1sub1
         |-sub1sub1sub1sub1
    |-sub1sub2
  |-sub2
    |-sub2sub1
    |-sub2sub2
  |-sub3
    |-sub3sub1
    |-sub3sub2

如果我们遵循“客户端只需要知道根URI ”的方法，那么客户端应该只知道根URI，即上面的/ collection1，其余的URI应该由客户通过超媒体链接。我发现这很麻烦，因为每次客户端需要进行GET时，比如sub1sub1sub1sub1，如果客户端首先对/ collection1执行GET并在返回的表示中定义跟随链接，然后在子资源上执行几次GET以达到想要的资源？或者我对连通性的理解是完全错误的？

祝你好运， 苏雷什

Answer 1

当您尝试构建与使用API​​的用户代理程序流不匹配的REST API时，您将遇到此不匹配问题。

考虑当您运行客户端应用程序时，始终会向用户显示一些初始屏幕。如果您将此屏幕上的内容和选项与根表示相匹配，则可用链接和所需的转换将很好地匹配。当用户在屏幕上选择选项时，您可以转换到其他表示，并且应该更新客户端UI以反映新的表示。

如果您尝试将REST API建模为某种链接数据存储库并将客户端UI建模为一组独立的转换，那么您会发现HATEOAS非常痛苦。

Answer 2

是的，客户端应用程序应该遍历链接是正确的，但是一旦发现了资源，保持对该资源的引用并使用它比一个请求更长的时间没有任何问题。如果您的客户有可能永久记住事物，那么就可以这样做。

考虑网络浏览器如何保留其书签。您可能在浏览器中有十个或一百个书签，并且您可能在页面层次结构中找到了一些这些书签，但浏览器会尽职尽责地记住它们而不需要记住找到它们所需的路径。

更丰富的客户端应用程序可以记住sub1sub1sub1sub1的URI，并在它仍然有效的情况下重用它。它可能仍然代表同样的事情（它应该）。如果它不再存在或因任何其他客户原因（4xx）而失败，您可以追溯您的步骤，看看您是否能找到合适的替代品。

当然达雷尔米勒说： - ）

Answer 3

我认为这不是严格的要求。根据我的理解，客户端直接访问资源并从那里开始是合法的。重要的是你不要为状态转换执行此操作，即在/ foo1等操作后不会自动继续使用/ foo2。最初检索/ products / 1234编辑它似乎完全没问题。服务器总是可以返回，例如，重定向到/ shop / products / 1234以保持向后兼容（这对于搜索引擎，书签和外部链接也是如此）。