3

我想使用带有超媒体约束的 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 是否应该检查资源上可用的链接，或者我该怎么做？

4

2 回答 2

2

对，就是这样。UI 应该完全按照呈现给它的链接关系进行编码。如果关系不可用，则不应在响应的链接集合中返回它。这不仅驱动当前状态，还意味着 UI 不会因尝试计算访问控制规则而负担。

于 2013-11-16T20:44:56.920 回答
0

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

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

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

他的意思是要把你所有的精力放在弄清楚如何设计一种数据格式及其规则上，这样系统就可以完全表达它的所有需求，比如 HTML。

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

于 2018-12-07T11:39:58.610 回答