连通性和HATEOAS

据说,在一个定义良好的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以达到想要的资源？或者我对连通性的理解是完全错误的？

最好的问候,Suresh

当您尝试构建与使用API​​的用户代理的流程不匹配的REST API时,您将遇到此不匹配.

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

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