RESTful API HATEOAS

我得出的结论是，构建一个真正的RESTful API，一个使用HATEOAS的API几乎是不可能的

我遇到的每一个内容都不能说明HATEOAS的真正力量 或者只是没有明确提到HATEOAS的动态特性所固有的痛点

我相信HATEOAS的全部内容是： 根据我的理解，一个真正的HATEOAS API应该拥有与API交互所需的所有信息，尽管这是可能的，但使用不同的堆栈尤其是这样做是一场噩梦

例如，考虑位于“/BooS”的资源集合及其响应：

{
“项目”：[
{
“自我”：“/book/sdgr345”，
“id”：“sdgr345”，
“名称”：“构建一个RESTful API——不言而喻的真相”，
“作者”：“Elad Chen；”，
“已出版”：1607606637049000
}
],
//这描述了创建新书所需的每个字段
//就像服务器上呈现的超文本标记语言（即HTML）处理表单一样
“创建表单”：{
“href”：“/书籍”，
“方法”：“发布”，
“rel”：[“创建表单”]，
“接受”：[“应用程序/x-www-form-urlencoded”]，
“字段”：[
{“name”：“name”，“label”：“name”，“type”：“text”，“max length”：“255”，“required”：true}
{“名称”：“作者”，“标签”：“作者”，“类型”：“文本”，“最大长度”：“255”，“必需”：true}
{“姓名”：“作者”，“标签”：“发布日期”，“类型”：“日期”，“格式”：“年月日”，“必填项”：true}
]
}
}

给出上述响应后，客户端（如web应用程序）可以使用“create form”属性呈现实际的HTML表单

我们从这些工作中得到了什么价值

多年来我们一直从HTML中获得相同的值。

想想看，这正是超文本的全部内容，也是HTML的设计初衷

当浏览器点击“www.pizza.com”时，浏览器不知道用户访问的其他路径 可以访问，它不会连接字符串以生成指向订单页面->www.pizza.com/order的链接，它只是呈现锚
并在用户单击时进行导航。这就是允许web开发人员在不更改任何客户端（浏览器）的情况下，将路径从“/order”更改为“/shutp and take my money”

上述想法同样适用于表单，浏览器不会猜测订购比萨饼所需的参数，他们只是呈现表单及其输入，并处理其提交

我在前端和后端都看到了太多的代码行，它们构建了字符串
比如——>”https://api.com“+”/order“-你看不到浏览器会这样做，对吗？

HATEOAS的问题 给出上面的例子（“/books”响应），为了创建一本新书，客户机需要解析响应以利用这个RESTful API的真正功能，否则，他们可能会假设字段的名称是什么，哪些是必需的，预期的类型是什么，等等

现在考虑在你的公司里有两个使用这个API的客户， 一个用于用JS编写的web（浏览器），另一个用于用Java编写的移动设备（比如android应用程序）。它们可以作为SDK发布，希望让第三方消费者更容易集成

一旦API被您无法控制的客户机使用，比如说与python有亲缘关系的第三方开发人员，目的是创建一本新书。
开发人员需要解析这样一个响应，弄清楚参数是什么，它们的名称，发送输入的URL，等等

在我多年的开发过程中，我还没有遇到过像我心目中那样的API。 我有一种感觉，这种类型的API只不过是一个白日梦，我希望在开始实现阶段之前了解我的假设是否正确，以及它会带来什么样的失败

附言

---

如果不清楚，这正是HATEOAS兼容API的全部内容-当创建书籍更改客户端的字段适应而不中断时。

实现HATEOAS API需要在服务器和客户端上完成，因此您在评论中提出的这一点确实非常有效：

更改资源URI是有风险的，因为我不相信客户端实际上“导航”API

除了万维网，这是HATEOAS的最佳实现，我只知道。大多数API都没有充分利用HATEOAS，只是一堆有文档的URL，您可以在其中获取或提交特定的资源（基本上，它们不是“超媒体驱动”，而是“文档驱动”）。使用这种类型的API，客户机实际上并不导航API，而是将字符串连接到特定的端点，在那里可以找到特定的资源

如果您公开了HATEOAS API，任何客户端的开发人员仍然可以查看您返回的链接，并可能决定自己构建它们，因为他们知道API在做什么，因此认为他们可以绕过可能需要的任何其他导航，直接访问URL，因为它总是

/products/categories/123

，直到——当然——它不再是了

HATEOAS API更难构建，并且会增加服务器和客户端的复杂性，因此在决定构建时，问题是：

• 您是否需要HATEOAS提供的灵活性来证明实现的额外复杂性
• 您想让客户端更容易还是更难使用您的API
• 双方（服务器开发人员和客户机开发人员）是否都具备使所有工作正常进行的知识和规程

大多数情况下，答案都是否定的。此外，很多时候问题甚至没有被问到，相反，人们最终会采用更为熟悉的方法，因为他们看到了人们构建、使用过或以前构建过的API。而且，很多时候，restapi只是被卡住了