我正在 ASP NET Core 中编写 Web API，我想从单页应用程序(例如使用 Angular、Vue、React)、 native 桌面应用程序和移动应用程序使用它。
我偶然发现了名为“HATEOAS” 的概念，并且了解到我正在构建的 API 并不是真正的 RESTful，我错误地将其命名为 RESTful (https://devblast.com/b/calling-your-web-api-restful-youre-doing-it-wrong)。
而且似乎大多数人都不好地使用这个术语(Roy T. Fielding - REST 背后的人关于他的烦恼:http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven)
据我了解，HATEOAS 背后的理念是像看待网站一样看待您的应用程序，这意味着它公开了指向资源的链接(如 HTML 中的 <a href.../>)，因此您不必对链接/端点进行硬编码如果您更改某些端点 (?)，您的客户端代码和您的客户端代码都不会中断。
另一件事是它使您的 API 无需任何文档即可被发现，即 API self 描述(如元 API)
例如，当我查看 C# 的现有“REST”客户端时:
他们的名字中有“REST”，但没有一个深入研究 HATEOAS 的概念。那么他们到底为什么被命名为“休息客户”呢？
HATEOAS 应该如何在客户端使用？令我惊讶的是，互联网上并没有太多关于它的内容，有很多关于如何在服务器上实现 HATEOAS 的内容，但没有太多关于它应该如何在客户端上工作的内容。这通常应该提供导航逻辑。
除此之外，还有许多 API 客户端生成器(解析 OpenAPI 规范)，例如 AutoRest (令我惊讶的是，与超链接和 HATEOAS 无关)或 NSwag
我在谷歌上搜索了几个小时以了解 HATEOAS，但大多数人谈论它时并没有描述如何使用它(几乎没有客户端库支持它)。
它有很多标准，比如HAL , Ion等等。但是几乎没有其他客户端库实现这些标准。还有 json:api .所有这些标准都非常相似。
所以我的问题是:
HATEOAS 是否适用于 SPA、移动和桌面客户端等应用程序？
HATEOAS 的真正用例是什么，如果我也可以硬编码我的端点，或者在 OpenAPI (Swagger) 规范发生变化时生成新的 API 客户端？
是否值得为此烦恼？
几乎没有与 HATEOAS 或超媒体 API 交互的实际示例，或者我在这里遗漏了一些东西，它们不应该被我的客户端代码使用？
对我来说，在客户端和服务器上实现它似乎是很多样板代码，那么为什么没有很多库支持它开箱即用(使用标准之一)。好像 json:api 有很多实现 http://jsonapi.org/implementations/#client-libraries-net
最佳答案
REST 是一种比 HTTP 协议(protocol)和所谓的“Web API”应用更广泛的范例。 RESTful Web API 是一种简单地将 REST 范例的原则应用于通过 HTTP 进行的客户端-服务器通信的 API。因此，它没有必要遵循 REST 中的所有内容，也不一定需要。
虽然 HATEOAS 是一个很好的概念，但实际上没有开箱即用的 HTTP 客户端(至少我知道)。你可以随意让你的 API 实现它，但这并不意味着它会被实际使用，虽然你的 API 可能是“RESTful”的，但这并不意味着每个客户端都会是。 HTTP 协议(protocol)的部分基础是自适应通信。换句话说，客户端不需要支持服务器的所有功能，反之亦然。相反，客户端和服务器使用它们在功能方面的共同点。
关于c# - 从本地客户端使用 HATEOAS API，REST 真的是 REST 吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/49916779/