Question

这可能是一个愚蠢的想法，但我想知道原因。

我正在阅读有关REST API的信息，以及HATEOAS等原则。一直以来，我都在想为什么人们不会仅仅使用HTML来表示他们的资源。

当然，我可以想到诸如解析困难和增加数据等缺点，但另一方面，它是一种语义超媒体语言，您可以使用它来将数据与表示分开。此外，它具有人类可读性，人们可以在浏览器中与其进行交互，关注链接，提交表单等。它既可以用作API，也可以用作UI。

任何人都可以解释为什么将HTML用于REST API表示是一个糟糕的主意吗？

Answer 1

任何人都可以解释为什么将HTML用于REST API是一个糟糕的主意表示？

是

形成不佳
客户如何一致地解析结果？
标记是详细的
它不是一种供机器消费的格式。这是人类的观点。 REST API适用于机器消耗。
大量响应会膨胀，并会导致更多的网络延迟。
至于演示文稿，您不能假设浏览器会使用API。原生Android / iOS应用程序怎么样？

Answer 2

www使用html进行REST！这个想法完全没有错。就个人而言，我首先要向你表示祝贺，很多人不这样做。

Rest并不强制要求应用程序协议，只是JSON / XML已经成为标准选择（因为HTML通常难以解析）。如果您使用HTML的简化版本，实际上可能会发现它比JSON更有用。

我编写了几个接受application / json和text / html进行内容协商的休息应用程序。它允许在浏览器上轻松测试。

正如您所提到的，它确实使HATEOAS更容易！ JSON（目前）没有处理HATEOAS或强类型的标准机制（大多数人使用@class方式指定json代表的对象）。 JSON在我看来还没有完成。

另一方面，XML是..但如果它不是一种XML，HTML是什么？

使用html：

<div name="Elvis Presley" id="1" class="com.graceland.elvis.Person">
    <a href="/people/12" id="12" class="com.graceland.elvis.Person">wife</a>
    <span name="country" class="java.lang.String">USA</span>
</div>

祝你好运，试图用Json复制它。 Json没有有效处理初学者的“属性”！

Answer 3

REST支持包含HTML的各种内容。很明显，大多数RESTful应用程序和Web API都专注于数据。因此，像JSON，XML和YAML这样的格式可以更方便地构建和解析。

但是如果你想利用REST的Conneg功能（基于标题Accept的内容否定），你可以根据调用者处理几种内容：

一个浏览器。也许我们更愿意显示HTML内容以显示请求的UI。你会得到：Accept: text/html。
一个应用程序。在这种情况下，您更期望一些结构化数据。你会有类似的东西：Accept: application/json，Accept: application/xml，等等。

实际上，这取决于RESTful应用程序。我构建了实现连接的RESTful应用程序，并根据指定的标头Accept发回了几种内容。

希望它有所帮助，亨利

Answer 4

REST是关于机器之间的通信。 HTML包含很多GUI元素，它还包含CSS，JS等等。所有这些都是供人类展示的。机器只对数据及其注释感兴趣。

顺便说一下。可以通过REST将HTML用作数据传输格式。例如，HAL具有（或只是？）HTML序列化格式，Hydra也可以使用HTML，例如与microdata。

如果您正在讨论浏览器和REST客户端（仅提取数据）可以使用的HTML，那么我认为通常很难编写这样的HTML文档。

Answer 5

tl; dr：如果我们认为XML对于REST API并不是一个糟糕的主意，那么我认为使用严格的XHTML子集（JSON是JavaScript的严格子集）是合理的。如果HATEOAS对您的API很重要。

HTML用于REST API的基本好处是<a href="">和<form action="">标签（您甚至可以将其简化为form标签）。它被定义为处理Hypermedia，并且是链接文档的唯一一种广为人知的方式。您无需阅读JSON-LD / HAL / Siren规范即可了解HTML的结构。

其他人对此表示反对，因为HTML包含<h1>标签。但是您可以使用严格的HTML子集，而不是尝试创建JSON的超集。 JSON实际上是JavaScript对象的严格子集。我个人认为这将使一个优秀的REST API –人和机器都易于理解。

我最初认为microdata与您想要的东西很接近，但是只能处理HTTP的GET，因此您需要用于处理所有其他HTTP方法的方法（因此需要{{1 }} 标签）。如果您只关心<form>请求，那么我认为这可能对您有用。您在其中的一条评论中询问了JSON-LD，在Schema.org wikipedia page中您可以看到微数据和JSON-LD之间的相似性。

微数据

GET

JSON-LD

<div itemscope itemtype="http://schema.org/Movie">
  <h1 itemprop="name">Avatar</h1>
  <div itemprop="director" itemscope itemtype="http://schema.org/Person">
  Director: <span itemprop="name">James Cameron</span> 
(born <time itemprop="birthDate" datetime="1954-08-16">August 16, 1954</time>)
  </div>
  <span itemprop="genre">Science fiction</span>
  <a href="../movies/avatar-theatrical-trailer.html" itemprop="trailer">Trailer</a>
</div>

我认为主要问题是HATEOAS不能为开发人员提供足够的切实利益，他们只是想传输没有自发现API的数据。自我发现并不重要，因为与您的API交互的人只需要发现一次相关的URL，然后只要您的API不变，他们就不必再在意了。此外，即使您确实编写了完全受HATEOAS支持的REST API，主要好处也应该是客户端不需要对URL进行硬编码，因此，更改URL并不重要。但是，您无法阻止API客户端 not 对URL进行硬编码，因此，如果您确实更改了结构，那么您将遇到不满意的客户端。以网络为例，它是一个（大部分）正确实现的REST API，但是链接腐烂仍然是一个主要问题，因为每个人仍然依赖固定的URL。

然后，如果链接不是那么重要，则JSON的简单性胜出。能够如此自然地表示数组和对象都很难反对。编程语言的整个范围从根本上关心数组（列表）和对象（字典/映射）。您不能简单地用XML或HTML表示数组这一事实是一个主要缺点。

与此相对的另一个问题是，大量的Web开发人员都在使用JavaScript进行编程，因此与JSON互操作是不费吹灰之力的，并且您必须具有说服老板使用其他功能的主要好处。

REST API，为什么没有HTML而不是JSON？

5 个答案:

微数据

JSON-LD