xml - 在实际使用中是否值得为 Restful Web 服务实现 HATEOAS？

Question

我已经阅读了很多有关将现有 Restful Web 服务转换为尽可能 HATEOS 的潜在好处的文章。我理解在有效负载中提供链接以减轻消费者记住下一个有效可用操作的负担的重要性。但是，我似乎无法完全理解它将如何在现实中帮助我的 Restful Web 服务的消费者。

为了说明，我以 Rest In Practice 中的这个例子为例关于点咖啡的书:-

<order xmlns="http://schemas.restbucks.com">
  <location>takeAway</location>
  <item>
    <name>latte</name>
    <quantity>1</quantity>
    <milk>whole</milk>
    <size>small</size>
  </item>
  <cost>2.0</cost>
  <status>payment-expected</status>
  <link rel="payment" href="https://restbucks.com/payment/1234" />
</order>

基本上，这允许消费者进行由 <link> 定义的付款标签。然而，实际上，消费者仍然需要知道该 Web 服务调用的所有语义，例如，使用什么方法(POST 或 PUT)，在负载中使用什么请求参数来进行支付等。 .. 换句话说，消费者仍然需要依赖 WADL 文档来了解如何成功调用此 Web 服务。如果这些标签都对一个特定项目使用 GET，则这些标签可能更有意义。否则，我真的看不出在这里定义链接有什么好处……除了消费者知道他们下一步可以调用什么操作，然后引用 WADL 以确定如何正确调用它之外。

我的下一个担忧是所有 <link> 可能会导致非常重的有效负载。标签。例如，如果/projects/1/users 上的 GET 返回属于项目 1 的所有用户信息，我假设我最终会得到以下标签:-

<project>
    <users>
        <user id="12" name="mike" ... />
        <user id="23" name="kurt" ... />
        <user id="65" name="corey" ... />
    </user>
    <links>
        <link rel="self" href="http://server/projects/1/users"/>
        <link rel="create_user" href="http://server/projects/1/users"/>

        <link rel="get_user_mike" href="http://server/projects/1/users/12"/>
        <link rel="get_user_kurt" href="http://server/projects/1/users/23"/>
        <link rel="get_user_corey" href="http://server/projects/1/users/65"/>
        ...
    </links>
</project>

如果一个项目包含 500 个用户……我不会在有效负载中有 500 个用户链接吗？否则，重新设计我的 Web 服务以处理这种情况的最佳方法是什么？或者这在现实世界中可以接受吗？

非常感谢任何想法或建议。谢谢。

Answer 1

要思考为什么这样做是正确的，想象一下没有 HATEOAS 方法的 API:您必须在文档中(或者在您的 WADL 中，如果您喜欢的话)发布每个可能的 URI 方案，并从你的这一点不能改变他们而不破坏你的客户。

本质上，您的客户将与您选择的 URI 布局密不可分。这种耦合程度很容易避免，只需记录媒体类型中的链接位置，而不是记录链接的外观。

也就是说，您的应用程序需要采用这种方法可能没问题，这很好。请记住，您将在很长很长一段时间内受制于 URI 布局。你会在good company虽然。