11

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

最好的问候， 苏雷什

4

3 回答 3

6

当您尝试构建与使用 API 的用户代理的流程不匹配的 REST API 时，您将遇到这种不匹配。

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

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

于 2010-07-14T16:03:29.133 回答
4

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

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

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

当然还有达雷尔米勒所说的:-)

于 2010-07-14T22:56:40.797 回答
0

我不认为这是严格的要求。据我了解，客户直接访问资源并从那里开始是合法的。重要的是您不要为状态转换执行此操作，即在操作 /foo1 后不要自动继续执行 /foo2 等等。最初检索 /products/1234 以对其进行编辑似乎非常好。服务器总是可以返回，比如说，重定向到 /shop/products/1234 以保持向后兼容（这也是搜索引擎、书签和外部链接所需要的）。

于 2010-07-14T14:24:29.467 回答