在现实世界中使用Restful Web服务是否值得实现HATEOAS？

Question

在现实世界中使用Restful Web服务是否值得实现HATEOAS？

lim*_*imc 17 xml rest web-services hateoas

如果我将现有的Restful Web服务转换为尽可能的HATEOS,我一直在阅读很多关于潜在好处的内容.我理解在有效负载中提供链接的重要性,以减少消费者在记住下一个有效可用操作时的负担.但是,我似乎无法理解它将如何帮助我的Restful Web服务的消费者实际.

为了说明这一点,我从" 休息实践"一书中摘取了关于制作咖啡订单的例子: -

<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>

Run Code Online (Sandbox Code Playgroud)

基本上,这允许消费者进行由<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>

Run Code Online (Sandbox Code Playgroud)

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

任何想法或建议在这里都非常感激.谢谢.

Answer 1

Bri*_*lly 9

想想为什么这是正确的做法,想象你的API没有HATEOAS方法:你必须在你的文档中(或在你的WADL,如果这是你的东西)发布每个可能的URI方案,并从那时开始如果不打破你的客户,你就无法改变它们.

从本质上讲,您的客户将与您选择的URI布局密不可分.这是一种耦合程度,您只需记录链接在媒体类型中的位置,而不是记录链接的外观,即可轻松避免.

也就是说,您的应用程序可能需要采用这种方法,这很好.请记住,您将长时间陷入URI布局.不过你会很好.

+1 ...感谢您的反馈.在我看来,无论是否采用HATEOAS方法,WADL都无法逃脱,因为最后,我仍然需要记录方法用法和我的API可能需要的所有必需参数(请求,标题等) .当我有一天改变URI模式时你提出了不打破客户端代码的一个好点,但如果它没有解决客户端代码实际上与我的API紧密耦合的事实......(继续) (7认同)
想象一下,如果我在/ login上有一个POST接受2个请求参数("用户"和"密码"),有一天我决定更改参数(例如,通过重命名或添加新参数),它仍会破坏客户端代码即使URI是稳定的.我看待它的方式是HATEOAS在某些情况下肯定有帮助,但在其他情况下它完全没用,这让我想知道它是否值得采用HATEOAS. (3认同)

Answer 2

lau*_*ent 5

对于您的特定示例,我认为回归HTML是有意义的.如果您在HTML中显示500个资源的列表,是否会包含指向每个资源的链接,以便用户可以获得更多信息？你可能会.REST API没有太大区别 - 如果返回500个资源的列表,则需要包含500个链接,以便用户可以获得有关每个资源的更多信息.

期望客户基于某些ID或名称构建URL就像要求用户在浏览器的地址栏中手动键入URL.

这是一篇非常好的文章,特别是:

就像HTML文件通过标签相互链接一样,或者就像XML文件通过XLink链接到彼此一样,所有状态转移都必须完全作为对表示内部链接的反应

+1 ...感谢您的反馈.让我问你这个,看看你是否同意我的想法......`link`标签中的`rel`属性非常永久.消费者将始终基于`rel`属性进行查找以获取动态URI.但是,消费者STILL需要知道如何通过引用WADL或某些文档来调用动态URI.听起来不错吗？从Restful Web服务中包含指向WADL的链接是否常见？ (3认同)

归档时间：	13 年，5 月前
查看次数：	2939 次
最近记录：	8 年，1 月前