问REST HATEOAS (成熟度级别3)有多重要？

EN

我们正在构建一个REST level 3 API，其中我们的响应是HAL-Json。HATEOAS对于前端和后端都很好，但它也带来了挑战。我们为在HAL-Json响应中管理ACL做了一些定制/添加(这不会违反HAL-Json标准)。

在我看来，HATEOAS最大的优点是我们不需要在前端应用程序上编写/猜测任何urls。您所需要的只是一个入口点(https://hostname)，从那里开始，您就可以使用响应中提供的链接或模板链接来浏览资源。就像这样，版本控制可以很容易地处理，重命名/替换urls，用额外的关系扩展资源，而不会破坏前端代码。

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

使用HAL-Json的另一个好处是，响应模型应该是什么样子是很清楚的，因为有一个应该遵循的文档标准。

我们的定制之一是在自链接对象中添加一个actions对象，该对象向前端公开通过身份验证的用户可以在相应资源(create:POST、read:GET、update:PUT、edit:PATCH、delete:DELETE)上执行的操作或CRUD操作。就像这样，我们的前端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"
}

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

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

我认为休息3级很好，但它可能会导致一些令人头痛的问题。你需要对REST有一个很好的理解，如果你想使用第3级REST，我建议你严格遵循REST的概念，否则你很容易在实现它的过程中迷失方向。

在我们的例子中，我们的优势是我们同时构建了前端和后端，但原则上这不应该有什么不同。但我在我们的团队中看到的一个常见陷阱是，一些开发人员试图通过更改他们的后端模型来解决前端问题(架构)，以便“适合”前端需求。

我在一些实际项目中使用过HATEOAS，但与Richardson的解释不同。如果这是你的老板想要的，那么我想你应该直接去做。我认为HATEOAS意味着您的资源应该包括HTML文档类型、相关资源的超链接和HTML表单，以公开除GET之外的谓词的功能。(这是当接受类型为text/html时-其他内容类型不需要这些额外的内容。)我不知道整个应用程序中的所有REST资源都必须粘合在一起的想法是从哪里来的。网络应用程序应该包含多个资源，这些资源可能直接相关，也可能不直接相关。或者为什么人们认为XML、JSON和其他类型需要遵循这一点。(HATEOAS是特定于HTML的。)