REST API，为什么不使用HTML而是JSON？

Question

REST API，为什么不使用HTML而是JSON？

htmljsonapirestrepresentation

8

这可能是一个愚蠢的想法，但我还是想知道为什么。

我正在阅读关于REST API和HATEOAS等原则的内容。一直在想，为什么人们不只是使用HTML来表示他们的资源呢？

当然，我可以想到一些缺点，比如解析困难和数据增加，但另一方面，它是一种语义化超媒体语言，你可以将数据与展示分离。而且，它是人类可读的，人们可以在浏览器中与之交互、跟随链接、提交表单等。它可以被用作API和UI。

有人能解释一下为什么使用HTML来表示REST API是个糟糕的想法吗？

- Willem-Aart

HTML规范并不适合真正表示数据。然而，XML足够灵活。 - R Day

这是不切实际的。HTML带有标签，其主要目的是为了结构化页面上的内容，以供人类查看。当使用REST时，预期的消费者是另一个应用程序。而程序并不关心标题是大还是小，是否有段落等。简而言之，您基本上需要像JSON提供的东西：具有对象和数组的简单可结构化数据格式。有了这个，您可以做任何想做的事情。 - Fiisch

@Fiisch XML也不提供数组，但人们仍然使用XML来构建REST API。 - icc97

5个回答

6

有人能解释一下为什么在REST API表示中使用HTML是一个可怕的想法吗？

可以。

- HTML格式不规范。 - 客户端如何保持一致地解析结果？ - 标记冗长。 - HTML不是面向机器的格式，而是用于展示给人类观看。REST API应该是面向机器的。 - 大型响应会导致网络延迟。 - 关于展示方面，不能假定API将由浏览器使用，那原生的Android/iOS应用呢？

- Deepak Bala

同意，你需要一些灵活性，可以在许多平台、演示文稿和代码库之间进行序列化和反序列化。 - kwelch

2

它可以被良好地形成（XHTML），标记不需要比XML更冗长。你反对的其余论点似乎只是JSON与XML之间的区别。如果我们假设XML不是REST API的可怕想法（许多人已经这样做了），那么这里没有任何理由说明为什么使用严格的XHTML子集（类似于JSON是JavaScript的严格子集）而不是XML会很糟糕。特别是如果HATEOAS对您的API很重要，那么XHTML似乎是一个合理的选择。 - icc97

6

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

但是，如果您想利用REST的Conneg功能（基于头部Accept的内容协商），则可以根据调用者处理多种内容：

浏览器。也许我们更喜欢显示HTML内容以显示请求的UI。您将获得： Accept: text/html。
应用程序。在这种情况下，您更期望一些结构化数据。您将获得类似于以下内容：Accept: application/json、Accept: application/xml等。

实际上，这取决于RESTful应用程序。我构建了实现conneg并根据指定的头Accept返回多种内容的RESTful应用程序。

希望对您有所帮助，Thierry

- Thierry Templier

不仅仅是你。:-) 比较 http:/start.spring.io 和 CURL 以及浏览器。 - epox

2

REST是关于机器之间的通信。HTML包含许多GUI元素，它还包括CSS、JS等等...所有这些都是为了人类显示视图。机器只对数据及其注释感兴趣。

顺便说一下，REST可以使用HTML作为数据传输格式。例如HAL有（或刚刚有？）一个HTML序列化格式，Hydra也可以使用HTML，例如microdata。

如果你说的是既可以被浏览器又可以被REST客户端（仅提取数据）使用的HTML，那么我认为编写这样的HTML文档通常很困难。

- inf3rno

1

简而言之：如果我们假设XML不是REST API的可怕想法，我认为使用XHTML的严格子集（JSON是JavaScript的严格子集）是合理的，特别是如果HATEOAS对您的API很重要。

HTML作为REST API的基本好处在于<a href="">和<form action="">标签（甚至可以将其简化为只有form标签）。它被定义为处理超媒体的方式，并且这是唯一一个被广泛理解的链接文档的方法。您不需要阅读JSON-LD / HAL / Siren规范来理解HTML的结构。

这里的其他人反对它，因为HTML包含<h1>标签。但是，您可以使用HTML的严格子集而不是尝试创建JSON的超集。 JSON实际上是JavaScript对象的严格子集。个人认为，这将成为一个优秀的REST API - 既易于人类理解又易于机器处理。

我最初认为microdata与您想要的接近，但它仅处理HTTP的GET方法，您需要处理所有其他HTTP方法的方法（因此需要<form>标签）。如果您只关心GET请求，我认为那可能适合您。您在其中一条评论中询问了JSON-LD，并且在Schema.org wikipedia页面上可以看到microdata和JSON-LD之间的相似性。

microdata

<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>

JSON-LD

<script type="application/ld+json">+schema app
{ 
  "@context": "http://schema.org/",
  "@type": "web master",
  "name": "schema.org/person",
  "Struturedata": 
    { 
       "@type": "Person",
       "name": "chema mpnrroy josepinedamonroy",
       "birthDate": "10/19/1982"
    },
  "geng": "male",
  "Mecanismo":microdata. ".estructuredate./" validador
}
</script>

我认为主要问题在于HATEOAS没有为开发者提供足够的实际好处，他们只想传输数据而不需要一个自我发现的API。自我发现并不那么重要，因为与您的API进行交互的人员只需要发现相关URL一次，然后只要您的API不改变，他们就不必再关心了。此外，即使您编写了完全支持HATEOAS的REST API，其主要优点应该是客户端不需要硬编码URL，因此如果您更改了URL，也无所谓。但是，您无法阻止API客户端不硬编码URL，因此如果您真的更改了结构，那么您将会有不满意的客户。以Web为例，它是（大多数情况下）正确实现的REST API，但链接失效仍然是一个主要问题，因为每个人仍然依赖于固定的URL。

然后，如果链接并不那么重要，JSON的简单性就胜出了。能够如此自然地表示数组和对象很难反驳。整个编程语言的基本关注点都在于数组（列表）和对象（字典/映射）。XML或HTML中无法简单地表示数组是一个主要缺点。

另一个反对它的问题是，大部分网页开发者都在使用JavaScript编程，因此与JSON进行交互是易如反掌的。如果要说服老板使用其他工具，必须有重大的好处。

- icc97

我认为这是这里更好的答案之一。然而，我不确定“您无法在XML或HTML中简单地表示数组是一个重大缺点”的说法是否正确。在HTML中，<ul>可用于数组/列表，<dl>可用于字典/映射，这是否正确？ - Simon Elms

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Richard · Accepted Answer

www使用HTML进行REST！这个想法并没有任何问题。个人认为，你在首先质疑这个想法时并没有做错什么，很多人都不会这么做。

REST不强制规定应用程序协议，只是JSON/XML已经成为标准选择（因为HTML通常很难解析）。如果您使用了一个简化版本的HTML，您可能会发现它比JSON更有用。

我编写了几个REST应用程序，可以接受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不能有效地处理“属性”！