【问题标题】:Is the semantic of the data integral part of REST?数据的语义是 REST 的组成部分吗?
【发布时间】:2010-10-09 03:00:41
【问题描述】:

这是对要求explanation of REST 的问题的跟进。

正如您从 cmets 和我的回答中看到的那样,我们与 Darrel Miller 就资源的最佳媒体表示进行了小争论。我们进行了进一步的电子邮件讨论,导致了这个问题。

Darrel 和我对 REST 的理解的主要区别在于数据的语义是否是 REST API 的一部分。

Darrel 相信(我对他的话的解释 :-))数据的语义是 REST API 的重要组成部分,因此,选择的媒体表示应该反映它。因此,适当的 REST API 应该选择:

  • 像 ATOM 这样的知名媒体来表示数据,以便尽可能多的客户端可以原生地理解资源的语义;
  • 特定于应用程序的媒体类型,如 application/vdn.mycomany.mymedia,并希望客户端了解此媒体类型以便能够使用资源数据。 application/xml 不是很好的资源表示,因为它不代表媒体类型中的语义,但需要客户端更多地了解语义。

另一方面,我认为 REST API 是一个独立于实际数据表示的层。 API 暴露的媒体类型只是一个传递资源数据的容器。数据的实际语义是分开处理的。因此,不理解数据的客户端仍然可以使用 REST API。 Application/xml 是一种非常好的数据表示,因为它允许理解架构的客户端紧密耦合,但仍然允许不理解架构的客户端对资源进行一些基本处理。

因此,问题:数据语义是 REST API 的一部分吗?我们是否应该只选择实际上也代表数据语义的资源表示的媒体类型?

如果人们在他们的答案中发布一些引用,我会很感激,最好是来自 Roy 本人。 :-)

【问题讨论】:

    标签: rest semantics representation


    【解决方案1】:

    让我们从头开始:媒体类型的存在是为了向客户端提供一种格式,它可以使用它来决定下一步要做什么。没有 html 页面,浏览器就没有可访问的链接。如果没有 html 渲染器,浏览器将无法渲染页面并且不知道该做什么。

    没有媒体类型,客户端不知道它是否能够对字节流做任何事情。实际上,当客户端收到指定 application/xml 的标头时,除了获取 xml 解析器之外,它不知道该做什么。

    所以问题真的是,客户端是否应该能够在不查看消息内部的情况下根据 http 消息做出决定,还是应该去查看消息内部(或者更糟糕的是,先解析消息)以知道该怎么做。

    缺少媒体类型意味着您的客户端必须进行额外的窥视工作,或者更糟的是处理实体主体本身,然后才能做出决定,无论是渲染还是处理。现在,您必须为您可能想要处理的每种格式添加大量自定义行为,并且在此过程中松散了一些耦合。

    中介应该能够在不检查正文的情况下处理请求,这也是一个 http 基础,而且 application/xml 也是有问题的。

    现在,当您说媒体类型的语义是 API 的一部分或不是 API 的一部分时……什么构成 API?

    从客户端的角度来看,没有 API。有一个初始表示可以让客户决定下一步该做什么。媒体类型确实是客户端获取导航“API”所需信息的地方,因此没有表示就没有 API。

    此外,客户端应该只有三个知识:引导位置、HTTP 协议和媒体类型。第一个只是一个 URI,并没有传达超出继续所需的表示位置的内容。第二个已经有了很清晰的语义。第三个是您可以控制的,因为这是您与客户的合同。

    该合同规定,每当您想做某事时,该某事将具有语义:要添加客户,请使用 POST 将 application/vnd.acme.customer+xml 发送到 /customers。

    因此我的回答是:设计 REST 架构依赖于两个步骤:资源建模(在概念级别)和媒体类型构建。其他任何事情,你都可能做错了。

    【讨论】:

      【解决方案2】:

      查看来自 Mark Ba​​ker 的this 幻灯片集,了解有关 application/xml 为何不满足“自我描述”约束的更多解释。您还可以在他的博客上阅读许多帖子,包括 this ,其中他继续解释为什么 application/xml + 命名空间不等同于媒体类型。

      【讨论】:

        【解决方案3】:

        我认为没有必要对此过于迂腐。一个资源可以暴露多个表示;每个都有自己的语义(甚至还有多个语义维度)。如果一种表示不提供特定用例所需的语义,则公开提供的一种。

        因此,客户不 懂数据,还能消费 REST API。

        我不确定这是否是一个很好的试金石,可以判断什么可以或不可以做出体面的表示。可以使用文档但不能很好地理解它以对其进行任何操作的客户端有什么好处?我想我不明白“资源的基本处理”如何使 application/xml 成为比任意 1 和 0 的 blob 更好的选择?

        既然您要求提供参考资料,here's an article from Roy Fielding where he "proposes" a bitmap representation of social network graphs。我当然可以得到一台机器来显示这些位图,但是如果我不了解底层的社交网络图又有什么用呢?将表示更改为 application/xml 是否允许天真的客户端从中提取位图中未包含的其他含义?没有。

        【讨论】:

        • 嗯,问题不在于它是否是一个体面的表示,而是调用 API RESTful 是否仍然可以接受。 :-)
        • 我想这就是我认为没有必要如此迂腐的地方。某些陈述对某些客户来说自然会比其他人更有意义。我想我认为这是关于无语义表示质量的讨论,而不是就所谓的 REST 达成共识
        • 位图示例是一个有趣的例子,因为它推断 API 将返回图像媒体类型,但除了像素产生的视觉之外还有更多的语义含义。这绝对与我之前对罗伊所说的理解相矛盾。
        • 老实说,我现在不知道我站在辩论的哪一边。我觉得我在支持和反对你们两个:)
        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2013-06-27
        • 2020-08-14
        • 2021-04-28
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多