问题标签 [hateoas]

我对使用 REST API 构建 Web 服务很感兴趣。我一直在阅读有关 HATEOAS 的文章，许多示例通过将其与人类在网上冲浪时的行为进行比较来解释该概念。这让我在想，为什么不以人类和机器都可以轻松使用的方式构建 REST API？

例如，我有一个小部件的内部模型，该小部件具有部件号、价格等属性。当机器请求小部件列表时，我可以返回一个 JSON 表示。

当一个人通过他/她的网络浏览器请求相同的列表时，似乎我应该能够采用相同的内部模型并对其应用不同的视图来生成 HTML 响应。（当然，我会用其他页面元素来装饰 HTML 响应，例如页眉、页脚等）

这是一个明智的设计吗？为什么或者为什么不？是否有任何流行的网站实际上正在这样做？

我看到的最大缺点是用户没有明显的方法来删除资源。在我的用例中，我不会让用户修改或删除资源，所以这不会破坏交易，但一般来说，你会如何处理呢？

我最近在 SO 上阅读了这个讨论，有人评论说并非所有应用程序都适合基于 REST 的架构。
这里我所说的“基于 REST 的架构”是指 RESTful apis + HATEOAS 的全部内容。网络上的大多数示例都引用了“咖啡店”示例，它们通过创建订单的工作流程位突出了 Hateoas 部分 --> 更新/确认 --> 支付 --> 收货。那么 REST 最适合具有显着状态转换的应用程序，还是同样适用于其他类型的应用程序，在这些应用程序中，我们可能应该更多地考虑状态转换以让 REST 为我们工作

在 HATEOAS 范式中，REST 响应中的链接表示什么，一个动作还是一个资源？我有一个带有类型下拉菜单的订单。一些高级选项字段将根据这些选择加载到表单中。

按照 HATEOAS 范式，不应期望客户端知道或猜测从何处加载这些额外字段。因此，我为提供的每个选项都包含了 1 个链接。链接对象上的rel属性应该提供某种关于链接意图的文档。这是一个正确的实现吗？

'net 上流行的咖啡店示例（在 Ian Robinson 的演讲和 InfoQ 的一篇文章中）使用链接来识别下一个可用的状态转换。这些在精神上是等价的吗？

网络工作的原因是因为您不必对每个网站都采取二进制依赖关系。可能与不鼓励使用 Flash 和 Silverlight 的原因相同。使用自定义 SDK 使用 REST Web 服务是否与使用插件查看内容同义？

如果我要将现有的 Restful Web 服务尽可能地转换为 HATEOS，我已经阅读了很多关于潜在好处的信息。我理解在有效负载中提供链接以减轻消费者记住下一个有效可用操作的负担的重要性。然而，我似乎无法理解它将如何在现实中帮助我的 Restful Web 服务的消费者。

为了说明，我从关于制作咖啡订单的Rest In Practice书中举了这个例子：-

基本上，这允许消费者进行由<link>标签定义的付款。然而，实际上，消费者仍然需要知道该 Web 服务调用的所有语义，例如，使用什么方法（POST 或 PUT）、在有效负载中使用什么请求参数以进行支付等。 .. 换句话说，消费者仍然需要依赖 WADL 文档才能知道如何成功调用此 Web 服务。如果这些标签都在一个特定项目上使用 GET，则它们可能更有意义。否则，我真的看不到在这里定义链接有什么好处……除了消费者知道他们接下来可以调用什么动作，然后参考 WADL 来确定如何正确调用它。

我的下一个担忧是最终可能会导致带有所有<link>标签的非常重的有效负载。例如，如果 /projects/1/users 上的 GET 返回属于项目 1 的所有用户信息，我假设我最终会得到以下标签：-

如果一个项目包含 500 个用户……我不会在有效负载中有 500 个用户链接吗？否则，重新设计我的 Web 服务以处理这种情况的最佳方法是什么？或者这在现实世界中是否可以接受？

任何想法或建议都非常感谢这里。谢谢你。

我目前正在设计一个 REST Http api。（使用 HATEOAS 的东西，让客户“更简单”，避免客户做复杂的事情，而不是让 api 告诉他们该做什么......）

由于应用程序的社交特性，为了与应用程序交互，需要对用户进行身份验证，每个用户对数据的“视图”都会略有不同。我们以推特为例，它对每个人都会更容易。

为了对用户进行身份验证，我们将使用 OAuth，很简单。

因此，在客户端（ios 应用程序...）中，随机用户可能会看到一个用户列表，应该看到：

另一个用户可能会看到：

为了实现这一点，第一个解决方案是客户端（在 oauth 术语中，iphone/web/etc 应用程序）获取经过身份验证的用户关注的所有用户的列表，并且每次客户端显示列表时，比较每个具有关注用户列表的用户，以了解它是否应该显示“未关注”或“关注”。

请求/响应将是：

和

这似乎是相当的，无国籍的。好的。

现在，如果我想让客户端开发人员的生活更轻松，并直接在用户列表响应中嵌入每个用户相对于经过身份验证的用户的关系，该怎么办：

所以，问题：

• 它似乎打破了“无状态”的东西，它真的打破了REST无状态约束吗？
• 接下来，您认为 api 这样做是好还是坏？

如果http://example.com/foo和http://example.com/bar都代表相同的资源并且服务器不区分两者怎么办？如果它在形成应用程序状态引擎（遵循 HATEOAS）的文档中互换使用它们，以便/bar在某些上下文和/foo其他上下文中显示，会怎样？

这是 RESTful 吗？

这样做的一个潜在好处是将描述符附加到 URI，例如http://example.com/article/30204/The-Quick-Brown-Fox，为了书签、搜索引擎查询，以及一般来说，人们可能通过查看 URI 来识别它。

我需要为 RESTful Web 服务正式指定一个资源模型，并且我正在考虑将 XML Schema 作为一种规范语言。理想情况下，这种资源模型将促进 HATEOAS 风格的客户端开发。一些问题：

1) XML Schema 是正式指定 Web 资源的最佳选择吗？2) 是否应将每个资源标识为自定义媒体类型？3) 是否可以将资源的链接关系集定义为其模式规范的一部分？

谢谢，卡梅伦。

根据这个关于设计 RESTful 接口的优秀演示文稿，实现版本控制的首选方法是利用 Accept-header，使用类似的东西：

这对 XML Content-Types 非常有效，但是可以使用相同的方案对 JSON 等效项进行版本控制？

即，是否可以要求：

响应将类似于：

和 JSON 等价物（有点）：

我尝试遵循HATEAOS约定。对于每个响应，我将提供指向另一个页面的链接。

我知道我可以提供下一页的链接（用于记录分页）。我的问题是，我是否需要提供常见页眉和页脚的链接（包括登录/注销、导航栏、常见信息 - 关于我等）？