HATEOAS(REST 架构)的实际示例

发布于 2024-07-27 15:34:08 字数 316 浏览 8 评论 0原文

每个人可能都已经注意到,有很多假的/基本的 REST-API(它们实现了 HTTP-API 并将其称为 REST,而不遵循超文本作为应用程序状态引擎的要求,这导致Roy T. Fielding 的著名咆哮 ,第一个指定 REST 范式的人)。

我一直无法找到任何真正超文本驱动的 REST 实现的实际示例以及状态转换的相关应用程序特定媒体类型定义。

是否有此类实现的公开示例?

as everyone may have noticed, there are lot of fake/rudimentary REST-APIs in the wild (which implement a HTTP-API and call it REST without following the hypertext-as-the-engine-of-application-state requirement, which led to the famous rant of Roy T. Fielding, the man who first specified the REST-paradigm).

I've been unable to find any practical examples of a truly hypertext driven REST-implementation along with the associated application-specific media-type definitions for the state transitions.

Are there any publicly accessible examples of such implementations?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

三生池水覆流年 2024-08-03 15:34:08

它不是运行代码意义上的实现,但我真的很喜欢这篇文章“How to GET一杯咖啡”在 InfoQ 上。 它将在星巴克点咖啡的过程描述为 RESTful 协议。 这超越了典型的“一切都是资源”的 REST 介绍性文章,重点关注 HATEOAS。 强烈推荐。

Its not an implementation in the sense of running code, but I really like the article "How to GET a cup of coffee" on InfoQ. It describes the process of ordering a coffee at Starbucks as a RESTful protocol. This goes beyond the typical "everything is a resource" REST introductory article and focuses on HATEOAS. Highly recommended.

憧憬巴黎街头的黎明 2024-08-03 15:34:08

Sun Cloud API? 从介绍来看:

API 不预设 URI 空间中的特定结构。 起点是由云服务提供商提供的 URI,它标识云本身。 云的表示包含云中其他资源的 URI,以及可对其执行的操作(例如部署和启动虚拟机)的 URI。

背景故事也可能乐于助人。

How about the Sun Cloud API? From the introduction:

The API presupposes no particular structure in the URI space. The starting point is a URI, supplied by the cloud service provider, which identifies the cloud itself. The cloud's representation contains URIs for the other resources in the cloud, and also for operations which may be performed upon them (for example deploying and starting virtual machines).

The backstory might also be helpful.

听闻余生 2024-08-03 15:34:08

Netflix 有一个基于 HATEOAS 的 REST API,其中包含链接作为一部分的资源。

Netflix has a REST API based on HATEOAS that includes links as part of the resources.

穿透光 2024-08-03 15:34:08

Roy 的第四点实际上不是解决了 Sun Cloud API 的 RESTful 问题吗:

REST API 不得定义固定的资源名称或层次结构(客户端和服务器的明显耦合)。 服务器必须能够自由地控制自己的命名空间。 相反,允许服务器通过在媒体类型和链接关系中定义这些指令来指示客户端如何构建适当的 URI,例如在 HTML 表单和 URI 模板中完成的操作。 [这里的失败意味着客户端由于带外信息而假设了一种资源结构,例如特定于域的标准,这是面向数据的,相当于 RPC 的功能耦合]。

示例 1 已定义层次结构中的固定资源名称:

来自 Sun Cloud API:“...VDC 的表示将包括驻留在其中的集群的表示,而集群又包括 VM 的表示在每个簇内。”

示例2带外信息,例如特定领域的标准:

您必须拥有wiki页面内容(带外信息)才能知道“资源通信机制”对于云资源字段“uri”是 GET。

Isn't the RESTfulness of Sun Cloud API actually addressed in Roy's 4th point:

A REST API must not define fixed resource names or hierarchies (an obvious coupling of client and server). Servers must have the freedom to control their own namespace. Instead, allow servers to instruct clients on how to construct appropriate URIs, such as is done in HTML forms and URI templates, by defining those instructions within media types and link relations. [Failure here implies that clients are assuming a resource structure due to out-of band information, such as a domain-specific standard, which is the data-oriented equivalent to RPC's functional coupling].

Example 1 Fixed resource names in a defined heirachy:

From the Sun Cloud API: "... the representation of a VDC will include representations of the Clusters which inhabit it, which in turn include representations of the VMs within each cluster."

Example 2 out-of-band information, such as a domain-specific standard:

You have to have the wiki-page contents (out-of-band information) to know that the "resource communication mechanism" for the Cloud resource field "uri" is GET.

梦罢 2024-08-03 15:34:08

我意识到不久前有人问过这个问题,但我尝试通过一个简单的示例来演示“正确的”REST API 流程。 我尝试遵循罗伊的休息规则 - 也许它会有所帮助:
使用 REST 的 API 示例

I realized this was asked a while ago, but I took a stab at demonstrating a "proper" REST API flow for a simple example. I tried to follow Roy's rules for REST - perhaps it could help:
API Example using REST

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文