34

我正在设计一个 REST api 并尽可能地 RESTful。我想将HATEOAS合并到 json 响应中。

将 URL 添加到相关资源很容易，但对用于这些链接的结构进行了一些讨论。

我发现很多文章都使用了从ATOM提要中借用的结构：

"links": [ 
    {"rel": "self", "href":"http://example.org/entity/1"},
    {"rel": "friends", "href":"http://example.org/entity/1/friends"}, ... 
]

这提出了一些问题：

  • 为什么使用数组作为容器？根据我认识的一位 javascript 开发人员的说法，将链接作为对象的属性访问链接会更容易。例如：

    "self":    { "href":"http://example.org/entity/1" }, /* (facebook uses this) */  
"friends": { "href":"http://example.org/entity/1/friends", "type": "..."}

  • 是否有一个通用的 json 结构（除了再次适应 atom）来描述资源属性中的引用吗？（例如消息的发送者）。

    引用可能应该再次解析为 url，但是包含简单 id 会很糟糕吗？有一些像：

    "sender": { 
    "id": 12345,
    "href": "resource-uri"
}

我的想法是，虽然 HATEOAS 使客户不需要很多知识来使用 API，但我有点不愿意消除使用这些知识的可能性（比如通过构建链接来访问个人资料图片客户端而不首先查找用户）。

4

3 回答 3

26

我在 API-Craft google group 上重新启动了这个话题，并得到了一些很好的回应。

阵列设计的主要优点是：

  • 同一关系的多个链接
  • 同一链接的多个关系而无需再次编写链接
  • 订购链接的能力

原因地图具有更好的可访问性。

就结构而言，有很多可能性：

我想我会选择 HAL，因为它是最干净的解决方案，其余的看起来有点……对 json 来说很奇怪。

于 2012-10-25T06:46:28.973 回答
4

就结构而言，您可以尝试查看 HAL ( http://stateless.co/hal_specification.html ) 或 JSON-LD: ( http://json-ld.org/ )

于 2012-10-25T05:47:39.067 回答
1

我认为这样您就可以基于 http 方法提供多个链接。

例如

"links": [ 
    {"rel": "sender", "method":"post", "href":"http://example.org/entity/1"},
    {"rel": "sender", "method":"put", "href":"http://example.org/entity/1"}, ... 
]

也许你可以适应你的想法

"sender": { 
     "href":"http://example.org/entity/1",
     "methods": ["put","post"]
}
于 2017-11-09T17:41:19.187 回答