Rest web浏览器是否完全符合HatEoAS标准？

REST架构的发明者罗伊·菲尔丁（RoyFielding）在一篇现在很有名的文章中批评了RESTful一词的滥用。特别是，他区分了RPC和REST接口

我对这一点的理解是，在RPC接口中，所有状态转换方法，包括它们的位置和含义，都是客户机事先知道的，然而，在REST接口中，客户机和服务器只需要说一种公共语言，就可以拥有一种共享的媒体类型，这种媒体类型具有先验语法和语义，它描述了应用程序状态以及状态转换方法的位置和意义，并且客户机在运行时发现了实际可用的方法

我可以看到，当客户机-服务器的情况是一种特殊的情况（比如智能灯泡与其网桥连接）时，这是一个非常重要的约束，但是当客户机-服务器的关系是web浏览器和web服务器的关系时，上面的RESTfulity约束不是很容易满足吗

---

这假设可能由服务器交付的JavaScript被视为表示的一部分，因此可以（例如）在不破坏RESTfusion的情况下随意包含硬编码链接。另一方面，我们也可以认为browser+js组合是实际的客户端，然后RESTfulness对js客户端的设计施加了一个非平凡的约束。但是这个观点不是很合理吗？

它对JS代码是一个非常重要的约束。JS应该被认为是一个客户机，而不是一个资源表示。确实两者都有，但只是从两个不同的角度来看。当JS戴着它的资源表示帽时，它是惰性的，不做任何事情。当它戴上REST客户端的帽子时，它是否作为资源表示的一部分就不再重要了

硬编码链接不是唯一的问题：JS代码连接字符串以使用内部信息构建链接也是一个问题。这些对REST的违反会影响可修改性的属性。当您认为JS代码和服务器实现通常被开发为同一项目的一部分时，这似乎不是一个问题。URI和客户端URI构建逻辑可以很容易地保持同步，对吗？但是，如果您有多个应用程序，它们自己的JS客户端共享一个服务器API实现，该怎么办？对URI的任何更改都会破坏许多客户端

JS代码应该与任何其他客户端一样受相同规则的约束：链接应该来自服务器提供的资源，语义应该来自对媒体类型的共同理解

一个具体的例子

假设我们有一个资源/readinglist/，它被定义为一个图书集合，如下所示：

{
    [
        {
        "id":"GoT",
        },
        {
        "id":"LOTR",
        },
        {
        "id":"IT",
        },
        ...
    ]
}

JS代码显示列表，如果用户单击某个项目，JS将获得相应的图书资源，以显示更多详细信息：

获取/读取列表/IT

{
    "id":"IT",
    "author":"Stephen. R. R. King"
}

这是所谓RESTAPI中非常常见的模式。但是这里发生的事情是，JS必须包含这样的逻辑，即通过将图书的id附加到集合的URL来检索图书。换句话说，客户机状态由带外信息驱动。您可能会争辩说，由于JS代码本身作为一种资源来自服务器，因此这并不是真正的带外信息。但是JS现在充当了一个客户端，因此应该进行分析

对比之下，考虑这个/读取列表/资源的表示：

{
    [
        {
        "id":"GoT",
        "link:"/books/GoT"
        },
        {
        "id":"LOTR",
        "link:"/books/LOTR"
        },
        {
        "id":"IT",
        "link:"/books/IT"
        },
        ...
    ]
}

---

现在JS不必知道如何连接URL。相反，它必须具有这样的逻辑，即通过遵循集合表示中的链接URL来获取图书资源。这有点复杂吗？差不多。关键区别在于，使用这种方法，客户机的状态由超媒体驱动，基于媒体类型的约定语义。一旦确定并标准化了媒体类型及其处理规则，就可以在多个API中重复使用

一般说来，浏览器是唯一真正的RESTful客户端，因此它们也必须符合HATEOAS。如果浏览器将加载一个包含链接的HTML页面，它将在给定一些其他信息（如链接文本或链接正在包装的某些图像）的情况下呈现该链接，并向用户呈现该信息。单击其中一个链接的决定由用户完成，用户只要求浏览器加载页面的新页面部分或任何内容，从而触发浏览器/客户端上的状态更改。必须进行的区分是，浏览器中运行的JavaScript通常是传输的服务器代码，服务器端通常包含特定的逻辑，页面重新加载时将重新加载这些逻辑。虽然JS客户机通常比客户机上安装的某些服务/应用程序更容易更新，但如果它假定某些资源具有特定类型的o，它可能会中断服务器端所做的更改

---

r结构。但实际的最终客户端仍然是浏览器，它将向用户呈现响应并等待进一步的交互。JS的主要用途之一是为最终用户提供有效的ui，至少在理论上可以将此JS代码视为客户端的一部分，因此，它的结构一般来说，它与服务器的关系是RESTful的。但是，由于JS客户机代码无论如何都是由服务器在运行时交付的，因此这种区别似乎没有什么实际价值，因为可以根据需要简单地更新JS客户机代码。是否有根据REST/HATEOAS原则构建的javascript客户机的实际例子？尽管这可能会使客户更加健壮，但在我看来，这也会使开发客户变得更加复杂。我无法向您指出任何实例，因此我尝试在我的答案中添加一个快速示例。谢谢，您的示例对我很有帮助。