【问题标题】:REST API vs Web APIREST API 与 Web API
【发布时间】:2019-08-24 05:11:30
【问题描述】:

我是构建 HTTP API 的初学者,我似乎对 REST API 和 Web API 之间的区别感到困惑。我在网上阅读了更多关于它的信息,似乎混淆了。我猜菲尔丁和这个链接有同样的问题http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

我在工作中构建了一个 HTTP API,以为我构建了一个 REST API,因为我在任何地方都在构建 Web/HTTP API 并将其称为 REST。

当我发现一个遵循 HATEOAS 原则的 API 是一个 Github REST API https://api.github.com。我尝试在 Github (GET https://api.github.com/users/vvs14) 上使用它作为我的用户名,它根据 HATEOAS 原则返回所有相关链接。

它是最接近 REST 规范的真实世界 API 之一,恕我直言。虽然我不明白哪个 URI 支持对它的什么操作,以及如果我是它的消费者,或者如果我托管 API,如何告诉消费者如何在任何 REST API 的情况下找到它?

一个不错的博客是https://www.e4developer.com/2018/02/16/hateoas-simple-explanation/

大多数博客中都给出了所有其他示例,只是告诉使用 JSON 作为 REST API,将所有内容作为资源作为 REST API,并使用 HTTP 动词进行 CRUD 操作作为 REST API。我不认为这些是真的。

在我的工作中,我使用 Sendgrid 的 Web API 向客户发送电子邮件,他们称之为 Web API,而不是 REST,我认为这很正确。

谁能用例子说明这两者之间的区别?

如果 Github API 是 REST API 的正确示例,我们如何知道哪个 URI 支持哪些操作,因为这里没有提到媒体类型?

【问题讨论】:

    标签: rest api web-services http web


    【解决方案1】:

    唯一可以告诉您它支持什么的资源是资源本身。资源为您提供的有关其他资源支持的任何信息纯粹是建议性的。找出答案的唯一真正方法是尝试并处理成功/失败。这是因为接受的请求可能每分钟都在变化(例如删除)。

    如果您的 API 可以在网络浏览器中导航并且可以提交表单(客户端除了起始 URL 和 HTML 格式之外对您的 API 一无所知)并且假设 text/html 是您 API 的可协商表示,那么它是RESTful。即使它不能在浏览器中导航,它也可以是 RESTful 的,但这更难演示。

    【讨论】:

      【解决方案2】:

      你是对的,有很多混乱。专家们通常将“真正的”REST API 称为 HATEOAS 或超媒体驱动的 API,以避免这种混淆。大多数确实称自己为 REST api 的 API 通常不是。

      因此,在与其他工程师讨论 REST api 时,首先澄清每个人认为 REST 而不是 REST 是有帮助的。他们不是不知道的坏工程师,“REST”这个词有它自己的生命,我会说 HATEOAS 可能更多的是一种小众技能。

      我同意 Nicholas Shank 的回答,即在许多情况下,要弄清楚例如 DELETE 是否有效,一般要做的事情是实际发出 DELETE,然后看看它是否有效。

      但这并不总是有帮助,因为许多构建 API 的人会希望在它无论如何都不起作用时不显示“删除”按钮。

      那么告诉客户DELETE 可用的合理方式是什么? HTTP 标准实际上确实有一个 Allow 标头,您可以使用它来找出在给定端点上工作的方法。要了解这些是什么,您可以发出OPTIONS 请求。并非每个框架都支持开箱即用,但这是一种合法的方式。

      另一种提前告知客户的方法是将此信息嵌入您正在访问的资源中。举几个例子:

      1. link hints 是一个互联网标准草案,它可以在各种不同的地方给出这些提示,例如 HAL、HTTP 链接头或其他。它基本上建议了此信息的通用格式。
      2. 如果您使用 OpenAPI 之类的东西,您可以在您的 API 规范中添加哪些方法可以工作,哪些方法不能工作。这适用于您知道 DELETE 根本不会起作用的情况,但在不同用户可能具有不同访问级别的情况下,它对您没有帮助,有些人可以使用 DELETE 而其他人可以不。
      3. 您可以将这些信息嵌入到您自己的格式中,将其表示为一组权限,可能是您的应用程序可以理解的 JSON 格式,以解释是否可以执行某些操作。
      4. 一些 HATEAOS 格式明确嵌入了有关可以通过操作执行何种操作的信息。一个很好的例子是SIREN 格式。 HAL 本身没有这个。

      最终,一个好的 HATEAOS 格式不仅会向他人返回有关资源和关系的信息,还会给出一组可以采取的潜在行动。 HATEAOS 的大多数 REST API 往往不这样做,但 HTML 是最好的例子。如果没有链接、按钮或表单来执行某项操作,则用户无法发现该操作。

      嵌入在 HAL 中的链接提示示例

      {
        "_links": {
          "self": {
            "href": "/orders/523",
            "hints": {
              "allow": ["GET", "DELETE"],
            }
          }
        }
      }
      

      SIREN 示例

       {
        "class": [ "order" ],
        "properties": { 
            "orderNumber": 523, 
        },
        "actions": [
          {
            "name": "delete-order",
            "title": "Delete Order",
            "method": "DELETE",
            "href": "/orders/523",
          }
        ],
        "links": [
          { "rel": [ "self" ], "href": "/orders/523" },
        ]
      }
      

      OPTIONS 响应

      HTTP/1.1 200 OK
      Allow: GET, DELETE
      

      【讨论】:

      • 很好的回应!我只是想知道链接提示和 HAL。给 HAL 规范不包含的链接添加额外的属性真的可以吗?
      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2011-08-23
      • 2013-11-29
      • 1970-01-01
      • 2016-12-20
      • 1970-01-01
      • 2020-11-14
      • 2018-10-27
      相关资源
      最近更新 更多