Хороший дизайн REST с Джексоном / Гсоном

Question

Хороший дизайн REST с Джексоном / Гсоном

1

Я развиваюсь с помощью Джексона уже пару лет, но меня всегда что-то беспокоило:

Мои модели на сервере имеют отношения друг к другу. Примером может быть следующее: у Lock есть Person которого есть список LogEntry и каждый LogEntry имеет Lock. Чтобы получить блокировку, я вызываю /api/lock/id и я получаю данные о лицах и журналах, однако LogEntry ссылается на Lock чтобы он стал бесконечным циклом.

Есть ли хороший способ/стандарт, который следует учитывать при разработке ваших моделей? Может быть, нужно только вернуть идентификатор ссылок?

Я хочу избежать круговых ссылок (что невозможно с аннотациями во многих случаях), но я также хотел бы избежать написания сериализаторов.

Есть ли у вас другие предложения? (FYI: Im чаще всего использует Backbone на стороне клиента)

Oscar Linde 03 сен. 2014, в 10:29

Источник

Теги:

java

json

rest

jackson

backbone.js

1 ответ

Ещё вопросы

Eric Stein · Accepted Answer · 2014-09-03T12-53-00.000Z

1

Лучший ответ

У вас есть несколько вариантов. Один из них заключается в том, чтобы возвращать ссылки на связанный элемент, а не встраивать весь ресурс. Если вам нужно, вы можете поддержать параметр запроса ?expand= который сообщает серверу о включении всего ресурса. Другой вариант заключается в создании отдельного ресурса для управления отношениями, таких как /log-entry-locks, которые могут выглядеть примерно так:

GET /log-entry-locks?log-entry=15
[{
    "id": 1345,
    "log-entry": "/log-entries/15",
    "lock": "/locks/22"
},
{
    "id": 1346,
    "log-entry": "/log-entries/15",
    "lock": "/locks/46"
}]

Eric Stein 03 сен. 2014, в 12:53

0

Мне нравится второй вариант, который вы продемонстрировали. Я думаю, что собираюсь попробовать это некоторое время и посмотреть, как это работает с Backbone. Большое спасибо!
Oscar Linde 05 сен. 2014, в 06:33
0

У вас есть другие решения, например, JSON-LD, и любой другой формат RDF может описывать графики. Или несколькими вызовами ваш клиент может запомнить URL-адреса уже найденных ресурсов, поэтому он не будет вызывать их снова ...
inf3rno 09 сен. 2014, в 01:11
1

Просто упомянуть, что использование гиперссылок с помощью REST не вариант, ваш клиент должен всегда использовать гиперссылку, созданную службой, для отправки запроса. (он же унифицированный интерфейс / ограничение HATEOAS)
inf3rno 09 сен. 2014, в 01:14
0

@ inf3rno не могли бы вы уточнить и, может быть, показать пример? Я посмотрел на JSON-LD, но не до конца понял, о чем идет речь.
Oscar Linde 11 сен. 2014, в 11:11
0

Он связывает словари RDF с данными, которые сервер отправляет вашему клиенту. Таким образом, клиент может понять, для чего нужны определенные части данных. Я предполагаю, что в настоящее время ваш клиент анализирует JSON, но не имеет представления о семантике свойств. Таким образом, он использует имена свойств для извлечения данных вместо семантики. С помощью JSON-LD вы можете добавить семантику к именам свойств, определив @context. Таким образом, ваш клиент может использовать семантику, чтобы найти правильное свойство вместо имени свойства, которое всегда может измениться. По ссылкам тоже самое, нужно добавить к ним семантику.
inf3rno 11 сен. 2014, в 13:54
0

В настоящее время большинство пользователей используют для этой цели HAL + JSON, отношения ссылок IANA и MIME-типы, специфичные для разных поставщиков. HAL + JSON - для описания интерфейса API REST, отношение ссылки - для описания значения ссылок, а специфичные для поставщика типы MIME - для описания тела сообщений. Это крупнозернистые решения. RDF - это мелкозернистое решение, но его сложнее понять и реализовать. Вы должны прочитать больше об этой теме, чтобы полностью понять ... RDF , Hydra REST vocab
inf3rno 11 сен. 2014, в 14:00

Показать ещё 4 комментария