代码之家  ›  专栏  ›  技术社区  ›  Suresh Kumar

连通性和憎恨

  •  11
  • Suresh Kumar  · 技术社区  · 14 年前

    据说,在一个定义良好的RESTful系统中,客户机只需要知道根URI或几个已知的URI,并且客户机应该通过这些初始URI发现所有其他链接。我确实了解这种方法的好处(分离的客户机),但对我来说,缺点是客户机每次尝试访问某些内容时都需要发现链接,即给定以下资源层次:

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

    如果我们遵循 客户端只需要知道根URI “这样一来,客户机应该只知道根URI,即上面的/collection1,其余的URI应该由客户机通过超媒体链接发现。我觉得这很麻烦,因为每次客户需要执行get时,比如在sub1sub1sub1sub1上,客户是否应该首先执行get-on/collection1和在返回的表示中定义的follow链接,然后再执行几个get-on子资源以获得所需的资源?或者我对连通性的理解是完全错误的?

    最好的问候, 苏雷什

    3 回复  |  直到 13 年前
        1
  •  6
  •   Darrel Miller    14 年前

    当您尝试构建一个与使用该API的用户代理流不匹配的RESTAPI时,会遇到这种不匹配。

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

    如果您尝试将您的RESTAPI建模为某种类型的链接数据存储库,将您的客户机UI建模为一组独立的转换,那么您会发现hateoas非常痛苦。

        2
  •  4
  •   mogsie    14 年前

    是的,客户机应用程序应该遍历链接是正确的,但是一旦发现了一个资源,保持对该资源的引用并将其使用超过一个请求的时间是没有错的。如果你的客户有永久记忆的可能性,他可以这样做。

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

    一个更丰富的客户机应用程序可以记住sub1sub1sub1sub1的URI,如果它仍然有效,就可以重用它。很可能它仍然代表着同样的东西(它应该如此)。如果它不再存在或由于任何其他客户机原因(4xx)而失败,您可以重新执行步骤,看看是否可以找到合适的替代品。

    当然,达雷尔·米勒是这么说的——)

        3
  •  0
  •   dzuelke    14 年前

    我认为这不是严格的要求。从我的理解来看,客户直接访问资源并从那里开始是合法的。重要的是,对于状态转换,您不执行此操作,即在操作/foo1等之后,不自动继续使用/foo2。最初检索/products/1234进行编辑似乎很好。例如,服务器总是可以返回到/shop/products/1234,以保持向后兼容(这对于搜索引擎、书签和外部链接也是可取的)。