使用超媒体约束 API 驱动 UI答案

【问题标题】：Using Hypermedia Constraint API to drive UI使用超媒体约束 API 驱动 UI
【发布时间】：2013-11-29 17:52:59
【问题描述】：

我想使用带有超媒体约束的 REST API 来驱动我的 UI。也就是说，根据我获取的资源的“可能的下一个状态”，我想为此调整我的 UI。我对网络上的 UI 开发还很陌生，所以我想知道这里是否有什么特别需要注意的事项？

假设我有一个如下所示的资源：

{
   href: "..",
   orderDate: date..,
   details: {
       href : "..",
       items: [..],
   }  
   links: [
   placeOrder : {
        href : "...",
        method : "post"
   },
   cancelOrder : {
        href : "...",
        method : "delete"
   }]
}

上述链接方法在 HATEOAS 的上下文中是否有效？在一个完美的世界里，我想人们应该只知道用于资源操作的 HTTP 动词，但是如果我想让 UI 知道可以对资源做什么，我该如何以惯用的方式做到这一点？

我的意思是，同一种资源可以有不同的“下一个可能的状态”，具体取决于当前状态。 UI 需要知道这一点。 UI 是否应该检查资源上可用的链接，或者我该如何检查？

【问题讨论】：

标签： html rest user-interface hateoas hypermedia

【解决方案1】：

是的，没错。 UI 应该完全按照呈现给它的链接关系进行编码。如果关系不可用，则不应在响应的链接集合中返回它。这不仅驱动当前状态，还意味着 UI 无需计算访问控制规则。

【讨论】：

【解决方案2】：

如果您的惯用意思是系统化，那么您返回的 JSON 处理规则的描述需要定义，那么您可以通过 Content-Type 标头传达您很酷的新媒体类型。

https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

REST API 应该将几乎所有的描述性工作都用于定义用于表示资源和驱动应用程序状态的媒体类型，或定义扩展关系名称和/或现有标准媒体的超文本启用标记类型。描述在感兴趣的 URI 上使用什么方法所花费的任何努力都应该完全在媒体类型的处理规则范围内定义（并且在大多数情况下，已经由现有媒体类型定义）。 [这里的失败意味着带外信息正在推动交互而不是超文本。]

他的意思是要全力以赴弄清楚如何设计数据格式及其规则，以使系统能够充分表达其所有需求，例如 HTML。

（或者跳过这个，只为您的 API 使用 HTML）。

【讨论】：