REST HATEOAS(成熟度级别 3)有多有用/重要? [英] How useful/important is REST HATEOAS ( maturity level 3)?

问题描述

我正在参与一个项目，其中一些高级团队成员认为 REST API 必须符合 HATEOAS 并实现 Richardson 的所有成熟度级别 (http://martinfowler.com/articles/richardsonMaturityModel.html)！

I'm getting involved in a project where some senior team members believe that a REST API has to be HATEOAS compliant and implement all Richardson's maturity levels (http://martinfowler.com/articles/richardsonMaturityModel.html)!

AFAIK 大多数 REST 实现不符合 HATEOAS 并且应该有一个很好的理由为什么更多的人不这样做.我可以想到一些原因，例如增加的复杂性、缺乏框架(服务器和客户端)、性能问题和......

AFAIK most REST implementations are not HATEOAS compliant and there should be a good reason why more people aren't doing it. I can think of reasons like added complexity, lack of frameworks (server and client sides), performance concern and...

你怎么看?您是否在实际项目中使用过 HATEOAS?

What do you think? Have you had any experience with HATEOAS in a real world project?

推荐答案

REST 社区中没有人说 REST 很简单.HATEOAS 只是增加 REST 架构难度的方面之一.

Nobody in the REST community says REST is easy. HATEOAS is just one of the aspects that adds difficulty to a REST architecture.

人们不会因为你建议的所有原因而做 HATEOAS:这很困难.它增加了服务器端和客户端的复杂性(如果您真的想从中受益).

People don't do HATEOAS for all the reasons you suggest: it's difficult. It adds complexity to both the server-side and the client (if you actually want to benefit from it).

然而，今天有数十亿人体验到 REST 的好处.你知道什么是结帐"?URL 在亚马逊?我没有.但是，我可以每天结帐.那个网址变了?我不知道，我不在乎.

HOWEVER, billions of people experience the benefits of REST today. Do you know what the "checkout" URL is at Amazon? I don't. Yet, I can checkout every day. Has that URL changed? I don't know it, I don't care.

你知道谁在乎吗?任何编写过屏幕抓取的亚马逊自动化客户端的人.有人可能会煞费苦心地嗅探网络流量、阅读 HTML 页面等，以找到要在何时使用哪些有效负载调用哪些链接.

Do you know who does care? Anyone who's written a screen-scraped Amazon automated client. Someone who has likely painstakingly sniffed web traffic, read HTML pages, etc. to find what links to call when and with what payloads.

一旦亚马逊改变了他们的内部流程和 URL 结构，那些硬编码的客户端就会失败——因为链接断开了.

And as soon as Amazon changed their internal processes and URL structure, those hard-coded clients failed -- because the links broke.

然而，休闲的网络冲浪者能够一整天都毫不费力地购物.

Yet, the casual web surfers were able to shop all day long with hardly a hitch.

这就是 REST 的作用，它只是由能够解释和直觉基于文本的界面、识别带有购物车的小图形并推测其实际含义的人类进行了增强.

That's REST in action, it's just augmented by the human being that is able to interpret and intuit the text-based interface, recognize a small graphic with a shopping cart, and suss out what that actually means.

大多数编写软件的人不会这样做.大多数编写自动化客户端的人并不关心.大多数人发现，当客户出现故障时修复它们比将应用程序设计为首先不损坏更容易.大多数人只是在重要的地方没有足够的客户.

Most folks writing software don't do that. Most folks writing automated clients don't care. Most folks find it easier to fix their clients when they break than engineer the application to not break in the first place. Most folks simply don't have enough clients where it matters.

如果您正在编写一个内部 API 来在两个系统之间进行通信，并且在流量的双方都有专家技术支持和 IT，他们能够快速、可靠地传达变更信息并制定变更计划，那么 REST 会为您买单没有什么.你不需要它，你的应用不够大，而且它的寿命也不够重要.

If you're writing an internal API to communicate between two systems with expert tech support and IT on both sides of the traffic, who are able to communicate changes quickly, reliably, and with a schedule of change, then REST buys you nothing. You don't need it, your app isn't big enough, and it's not long-lived enough to matter.

拥有庞大用户群的大型网站确实存在此问题.在与系统交互时，他们不能只是要求人们随心所欲地更改他们的客户端代码.服务器的开发计划与客户端的开发计划不同.API 的突然更改对于所有相关人员来说都是无法接受的，因为它会中断双方的流量和运营.

Large sites with large user bases do have this problem. They can't just ask folks to change their client code on a whim when interacting with their systems. The server's development schedule is not the same as the client development schedule. Abrupt changes to the API are simply unacceptable to everyone involved, as it disrupts traffic and operations on both sides.

因此，这样的操作很可能会从 HATEOAS 中受益，因为它更容易版本化，更容易让旧客户端迁移，更容易向后兼容.

So, an operation like that would very likely benefit from HATEOAS, as it's easier to version, easier for older clients to migrate, easier to be backward compatible than not.

将其大部分工作流程委托给服务器并根据结果采取行动的客户端比不这样做的客户端对服务器更改的鲁棒性要强得多.

A client that delegates much of its workflow to the server and acts upon the results is much more robust to server changes than a client that does not.

但大多数人不需要这种灵活性.他们正在为 2 或 3 个部门编写服务器代码，这些代码都是内部使用的.如果它坏了，他们会修复它，并将其纳入正常运营中.

But most folks don't need that flexibility. They're writing server code for 2 or 3 departments, it's all internal use. If it breaks, they fix it, and they've factored that into their normal operations.

灵活性，无论是来自 REST 还是其他任何东西，都会带来复杂性.如果你想要它简单、快速，那么你就不要让它变得灵活，你只是做"，然后就完成了.当您向系统添加抽象和取消引用时，事情会变得更加困难、更多样板、更多要测试的代码.

Flexibility, whether from REST or anything else, breeds complexity. If you want it simple, and fast, then you don't make it flexible, you "just do it", and be done. As you add abstractions and dereferencing to systems, then stuff gets more difficult, more boilerplate, more code to test.

大部分 REST 都失败了您不需要它"；要点.当然，直到你这样做.

Much of REST fails the "you're not going to need it" bullet point. Until, of course, you do.

如果您需要它，请使用它，并按原样使用它.REST 不会在 HTTP 上来回推送东西.从来没有，比那高得多.

If you need it, then use it, and use it as it's laid out. REST is not shoving stuff back and forth over HTTP. It never has been, it's a much higher level than that.

但是当您确实需要 REST 并且您确实使用 REST 时，那么 HATEOAS 是必要的.它是软件包的一部分，也是使其发挥作用的关键.

But when you do need REST, and you do use REST, then HATEOAS is a necessity. It's part of the package and a key to what makes it work at all.

示例:-为了更好地理解它，让我们看一下从服务器(http://localhost:8080/user/123)检索 id 为 123 的用户的以下响应>):

Example:- To understand it better let’s look at the below response of retrieve user with id 123 from the server (http://localhost:8080/user/123):

{
    "name": "John Doe",
    "links": [{
            "rel": "self",
            "href": "http://localhost:8080/user/123"
        },
        {
            "rel": "posts",
            "href": "http://localhost:8080/user/123/post"
        },
        {
            "rel": "address",
            "href": "http://localhost:8080/user/123/address"
        }
    ]
}

这篇关于REST HATEOAS(成熟度级别 3)有多有用/重要?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！