Я не смог найти четкого ответа, надеясь, что кто-то может помочь.

Если у нас есть, скажем, блог с постами, и у каждого поста могут быть комментарии, и у каждого комментария есть связанный пользователь. Противоречиво ли, если я запрашиваю комментарий, включить в отношения как пользователя , так и сообщение?

data: {
  type: 'comments',
  id: '1',
  relationships: {
    post: {...}, //should this be here?
    user: {...},
  }
  attributes: {...},
},
included: {...}
1
gjunkie 21 Авг 2018 в 02:51

3 ответа

Лучший ответ

Как paulsm4 правильно сказал: «это ваше дело».

Но я могу дать вам несколько советов по этому поводу.

В таких ситуациях вы можете предоставить вызывающей стороне API возможность выбора таких ссылок или нет с помощью флага строки запроса, например

?relationships=post,user

В этом случае, если вы не укажете флаг отношения, вы получите простые данные комментария или решите дать их все; во втором случае вы можете использовать отношения как своего рода фильтр.

В некоторых API я также видел более инвазивный подход: вставлять связанный объект непосредственно в возвращаемый JSON.

С той же техникой, что и раньше:

?embed=post,user

Это должно создать встроенный объект JSON в текущем ответе JSON, включая исходные объекты, так же, как вы спрашивали что-то вроде «GET / post / 123» или «GET / user / 456» отдельно. Это может быть удобно в некоторых ситуациях.

Часто этот флаг называется «раскрыть», обозначая то же или похожее поведение.

Для примера откройте эту документацию по API от Atlassian и искать "расширить".

Существует старый «стандарт» для вашей проблемы, который называется HAL, который говорит о связывании и внедрении в REST API. ,

Даже Wordpress API предлагает такие функции, посмотрите на официальная документация.

Альтернативой этому является переписывание всего API в GraphQL с использованием подхода REST.

1
Stefano Coletta 21 Авг 2018 в 00:54

Спецификация JSON API не предъявляет никаких требований к включению атрибутов и отношений в ресурсный объект . Спецификация просто говорит, как они должны быть отформатированы, если они включены. Если я ничего не пропустил, спецификация даже не требует, чтобы все объекты ресурсов одного типа имели одинаковые атрибуты и отношения .

Но я бы сказал, что нет никакой ценности в том, чтобы не включать отношения. Спецификация JSON API не требует объект отношений включить связь ресурсов . Напротив, речь идет только о данных о связях ресурсов в контексте составного документа , в котором он используется «для связывания всех включенных объектов ресурса без необходимости получать какие-либо URL-адреса с помощью ссылок».

Он полностью действителен и может считаться наилучшей практикой для предоставления только ссылка на связанный ресурс , если связанные ресурсы не включены в полезную нагрузку. Создание такой ссылки не создаст никакой нагрузки на ваш сервер, так как не требует запросов к базе данных. Это также не имеет никакого отношения к размеру полезной нагрузки.

Пример полезной нагрузки, использующей оба метода, будет выглядеть следующим образом. Предполагается, что в запросе явно просят включить связанного пользователя с помощью include параметра запроса,

// GET https://examples.com/api/v1/comments/1?include=user

{
  data: {
    type: 'comments',
    id: '1',
    relationships: {
      post: {
        links: {
          related: 'https://examples.com/api/v1/comments/1/post'
        }
      },
      user: {
        data: {
          type: 'users',
          id: '2'
        },
        links: {
          related: 'https://examples.com/api/v1/comments/1/user'
        }
      },
    }
  },
  included: [
    {
      type: 'users',
      id: '2',
      attributes: {
        name: 'John Doe'
      }
    }
  ]
}

Вы также можете добавить ссылку на отношения , который «позволяет клиенту напрямую манипулировать отношениями». Обновить отношения , глава, посвященная спецификациям, дает глубокое представление о что вы могли бы сделать, используя ссылки отношений.

-1
jelhan 11 Сен 2018 в 20:56

Вопрос: Должны ли сущности JSON API включать отношения для своего родителя?

A: Я полагаю, что это полностью зависит от вас!

Если ваш JSON определен какой-то третьей стороной, то вы должны жить с тем, что они вам дали. Пожалуйста, опубликуйте подробности о том, как указан JSON.

В противном случае, если вы «изобретаете» формат самостоятельно:

  1. Одна возможность состоит в том, чтобы иметь поле relationships: со ссылкой на «родителя».

  2. Возможно, лучшее решение могло бы изобрести «контейнер» (возможно, простой массив!) Для хранения ваших «записей».

  3. Если бы это была база данных, у меня была бы таблица "posts" и таблица "comments". Таблица "comments" будет содержать столбец "Post ID" в качестве внешнего ключа в таблице "posts".

Надеюсь, это поможет ... хотя бы немного ...

0
paulsm4 21 Авг 2018 в 00:00
51939865