REST HATEOAS(成熟度等级3)有用/重要吗？

REST社区中没有人说REST很容易.HATEOAS只是增加REST架构难度的一个方面.

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

然而,数十亿人今天体验到了REST的好处.你知道亚马逊的"结账"网址是什么吗？我不.然而,我每天都可以结账.该网址已更改？我不知道,我不在乎.

你知道吗？任何写过屏幕的人都会刮掉亚马逊的自动化客户端.有些人可能会煞费苦心地嗅探网络流量,阅读HTML页面等,以找到何时以及使用哪些有效负载调用哪些链接.

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

然而,休闲的网络冲浪者能够整天购物,几乎没有任何障碍.

这就是REST的实际应用,它只是通过能够解释和直观基于文本的界面,识别带有购物车的小图形以及实际意味着什么的人类来增强.

大多数编写软件的人都不这样做.大多数写自动客户的人都不在乎.大多数人发现在他们破解时更容易修复他们的客户,而不是设计应用程序而不是首先破坏他们.大多数人在重要的地方根本没有足够的客户.

如果您正在编写内部API,以便在两个系统之间进行通信,并且在流量的两端都有专家技术支持和IT,谁能够快速,可靠地和变更计划进行通信,那么REST就不会给您带来任何好处.你不需要它,你的应用程序还不够大,并且它的存在时间不长.

拥有大量用户群的大型网站确实存在此问题.他们不能只是要求人们在与系统交互时随心所欲地更改客户端代码.服务器开发计划与客户端开发计划不同.API的突然变化对所有参与者来说都是不可接受的,因为它会破坏双方的流量和操作.

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

将其大部分工作流委托给服务器的客户端,对结果采取行动对服务器更改的影响远远大于没有服务器更改的客户端.

但大多数人不需要这种灵活性.他们正在为2或3个部门编写服务器代码,这些都是内部使用的.如果它破裂了,他们会修复它,并且他们已经考虑到了正常的操作.

无论是来自REST还是其他任何方面,灵活性都会带来复杂性.如果你想要它简单,快速,那么你就不要灵活,你"只是去做",并且完成.当你添加抽象和解除引用系统时,东西变得更加困难,更多的锅炉板,更多的代码来测试.

很多REST都失败了"你不需要它"的要点.当然,直到你做到了.

如果你需要它,那就使用它,然后按照它的布局使用它.REST不会在HTTP上来回传递信息.它从来没有,它比它高得多.

但是当你确实需要REST时,你确实使用了REST,那么HATEOAS就是必需品.它是软件包的一部分,也是使其工作的关键.

理查森的成熟度3级很有价值,应该采用.JørnWildt已经总结了一些优势,另一个答案是Wilt,它非常好地补充了它.

然而,理查森的成熟度3级与菲尔丁的HATEOAS不同.Richardson的成熟度等级3仅与API设计有关.Fielding的HATEOAS也是关于API设计的,但也规定客户端软件不应假设资源具有超出媒体类型定义的结构的特定结构.这需要一个非常通用的客户端,如Web浏览器,它不了解特定网站.由于Roy Fielding创造了术语REST并将HATEOAS设置为符合REST的要求,因此问题是:我们是否希望采用HATEOAS,如果没有,我们仍然可以调用我们的API RESTful吗？我想我们可以.让我解释.

假设我们已经实现了HATEOAS.应用程序的客户端现在非常通用,但很可能,用户体验很糟糕,因为在不了解资源语义的情况下,无法定制资源的表示以反映这些语义.如果资源"car"和资源"house"具有相同的媒体类型(例如application/json),则它们将以相同的方式呈现给用户,例如作为属性表(名称/值对).

但没关系,我们的API非常RESTful.

现在,假设我们在此API之上构建第二个客户端应用程序.第二个客户端违反了HATEOAS的想法,并且有关于资源的硬编码信息.它以不同的方式显示汽车和房屋.

API仍然可以称为RESTful吗？我认同.它的一个客户违反了HATEOAS,这不是API的错.

我建议构建RESTful API,即理论上可以实现通用客户端的API ,但在大多数情况下,您需要一些有关客户端资源的硬编码信息,以满足可用性要求.尽管如此,尽量少尝试硬编码,以减少客户端和服务器之间的依赖关系.

我在我的REST实现模式中包含了一个名为JAREST的HATEOAS部分.

我们正在构建REST级别3 API，我们的响应在HAL-Json中进行。HATEOAS对于前端和后端都非常有用，但同时也带来了挑战。我们进行了一些自定义/添加，还用于在HAL-Json响应中管理ACL（这不会违反HAL-Json标准）。

我看到的HATEOAS的最大优点是，我们不需要在前端应用程序中编写/猜测任何url。您只需要一个入口点（https://hostname），然后就可以使用响应中提供的链接或模板链接浏览资源。这样，可以轻松处理版本控制，重命名/替换url，使用其他关系扩展资源而不会破坏前端代码。

使用自我链接在前端缓存资源是小菜一碟。我们还通过套接字连接将资源推送给客户端，因为这些资源也是在HAL中呈现的，所以我们可以轻松地以相同的方式添加它们以缓存。

使用HAL-Json的另一个优点是，很明显响应模型应该是什么样的，因为应该遵循一个成文的标准。

我们的一个自定义的是，我们增加了一个行动自链接对象的内部对象是哪些动作或CRUD操作验证的用户被允许在各自的资源执行暴露给前端（create:POST，read:GET，update:PUT，edit:PATCH，delete:DELETE）。这样，我们的前端ACL完全取决于我们的REST API响应，从而将这一责任完全转移到了后端模型上。

因此，举个简单的例子，您可以在HAL-Json中有一个post对象，看起来像这样：

{
    "_links": {
        "self": {
            "href": "https://hostname/api/v1/posts/1",
            "actions": {
                "read": "GET",
                "update": "PUT",
                "delete": "DELETE"
            }
        }
    },
    "_embedded": {
        "owner": {
            "id": 1,
            "name": "John Doe",
            "email": "john.doe@example.com",
            "_links": {
                "self": {
                    "href": "https://hostname/api/v1/users/1",
                    "actions": {
                        "read": "GET"
                    }
                }
            }
        }
    },
    "subject": "Post subject",
    "body": "Post message body"
}

现在，我们在前端要做的就是AclService用一种isAllowed方法构建一个，该方法检查我们要执行的动作是否在actions对象中。

当前在前端，它看起来很简单： post.isAllowed('delete');

我认为REST级别3很棒，但它可能会引起一些麻烦。您将需要对REST有深刻的了解，如果您想使用3级REST，我建议您严格遵循REST概念，否则在实现它时很容易迷路。

就我们而言，我们的优势在于我们同时在前端和后端进行构建，但原则上不应该有所作为。但是我在我们的团队中看到的一个常见陷阱是，一些开发人员试图通过更改后端模型来解决前端问题（体系结构），从而“满足”前端需求。

是的,我在API中有过超媒体的经验.以下是一些好处:

可探索的API:这可能听起来微不足道,但不要低估可探索API的强大功能.浏览数据的能力使客户端开发人员更容易构建API及其数据结构的心理模型.

内联文档:使用URL作为链接关系可以将客户端开发人员指向文档.

简单的客户端逻辑:简单地遵循URL而不是自己构建URL的客户端应该更容易实现和维护.

服务器获取URL结构的所有权:超媒体的使用消除了客户端对服务器使用的URL结构的硬编码知识.

将内容加载到其他服务:在将内容卸载到其他服务器(例如CDN)时,必须使用超媒体.

使用链接进行版本控制:超媒体有助于API的版本控制.

同一服务/ API的多个实现:当存在相同服务/ API的多个实现时,超媒体是必需的.例如,服务可以是具有用于添加帖子和评论的资源的博客API.如果根据链接关系而不是硬编码URL指定服务,则可以在不同的URL处多次实例化相同的服务,由不同的公司托管但仍然可以通过单个客户端通过相同的良好定义的链接集来访问.

你可以在这里找到这些要点的深入解释:http://soabits.blogspot.no/2013/12/selling-benefits-of-hypermedia.html

(这里有一个类似的问题:https://softwareengineering.stackexchange.com/questions/149124/what-is-the-benefit-of-hypermedia-hateoas我给出了相同的解释)