我应该如何处理HATEOAS链接和JSON中的引用？

编程入门行业动态更新时间:2024-10-17 20:26:46

本文介绍了我应该如何处理HATEOAS链接和JSON中的引用？的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！问题描述我正在设计一个REST api，并且像REST一样具有REST风格。我想将 HATEOAS 并入json回复。

向相关资源添加URL很简单，但有一些讨论用于这些链接的结构。

我发现使用一些文章从 ATOM Feed中借用的结构：

links：[ {rel：self，href：example/entity/1}， {rel：friends，href：example/entity/1/friends}，... ]

这提出了一些问题：

为什么要使用数组作为容器？根据我知道的一个JavaScript开发人员，使用链接作为对象的属性可以更容易地访问链接。例如：
self：{href：example/entity/1} ，/ *（facebook use this）* / friends：{href：example/entity/1/friends，type：...}
是否有一个常见的json结构（再次适配原子）描述资源属性中的引用（例如消息的发件人）。

引用应该可以再次解析为url，但是包含简单的id也是不好的类似：
发件人：{id：12345，href ：resource-uri}

<我的想法是，虽然HATEOAS使得客户不需要很多知识来使用API，但我不愿意删除使用该知识的可能性（如通过构建访问配置文件图片）

解决方案

我在API-Craft google group上重新启动了这个主题，有一些很棒的回应。

Array设计的主要优点是：

相同关系的多个链接
同一链接的多个关系，无需编写链接aggain
订购链接的能力

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

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

JSON-HAL： blog.stateless.co/post/13296666138/json-linking-with-hal 或也 stateless.co/hal_specification.html
JSON-LD： json-ld/ （可选地使用 Hydra 词汇）
JSON模式： http ：//json-schema/ （页面底部的Hyper Meta-Schema）
集合+ JSON： amundsen/media-types/collection/

我想我会和HAL一起去，因为它是最干净的解决方案，其余的都看起来很奇怪json。

I'm in the process of designing a REST api and to be as RESTful as it gets. I want to incorporate HATEOAS into the json responses.

Adding URLs to related resources is easy enough, but there was some discussion over the structure to use for those links.

A LOT of articles I found use a structure borrowed from ATOM feeds:

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

This raised some questions:

Why use an array as a container? According to a javascript developer I know, access to the links would be easier with the links as properties of an object. For example:
"self": { "href":"example/entity/1" }, /* (facebook uses this) */ "friends": { "href":"example/entity/1/friends", "type": "..."}
Is there a common json structure (beside adapting atom again) to describe references in resource properties? (for example the sender of a message).

The reference should probably be resolved as a url again, but would it be bad to include the simple id as well? kind of like:
"sender": { "id": 12345, "href": "resource-uri" }

My way of thought is that while HATEOAS makes it so a client doesn't need a lot of knowledge to use an API, I'm kind of reluctant to remove the possibility to USE that knowledge (like accessing the profile picture by building the link client-side without looking up the user first).

解决方案

I restarted this topic on the API-Craft google group and got some great responses.

The main advantages of the Array design are:

multiple links for the same relationship
multiple relationships for the same link without writing the link aggain
the ability to order the links

The map of cause has better accessibility.

As far as structure goes there are a lot of possibilities:

JSON-HAL: blog.stateless.co/post/13296666138/json-linking-with-hal or also stateless.co/hal_specification.html
JSON-LD: json-ld/ (optionally using Hydra vocabulary)
JSON-Schema: json-schema/ (theHyper Meta-Schema on the bottom of the page)
Collection+JSON: amundsen/media-types/collection/

I guess i will go with HAL as it is the cleanest solution, the rest all look kind of... strange for json.