Разреженные поля в сложных JSON атрибутах API - PullRequest
Новая
       35

Разреженные поля в сложных JSON атрибутах API

0 голосов
/ 28 февраля 2020

В соответствии с # document-resource-object-attribute разрешено иметь «сложные» значения для атрибутов, то есть любое допустимое значение JSON.

С # fetching-sparse-fieldsets можно выбрать подмножество содержимого. Однако все примеры соответствуют имени атрибута.

Например: 

{
  "data": [
    {
      "type": "dogs",
      "id": "3f02e",
      "attributes": {
        "name": "doggy",
        "body": {
          "head": "small",
          "legs": [
            {
              "position": "front",
              "side": "right"
            },
            {
              "position": "front",
              "side": "left"
            }
          ],
          "fur": {
            "color": "brown"
          }
        }
      }
    }
  ]

В результате меня интересуют только name, body.head и body.fur.color.

Что было бы правильно способ решить эту проблему (желательно без обязательных отношений, так как эти данные действительны)?

1 Ответ

0 голосов
/ 08 марта 2020

JSON: функция API Sparse Fieldsets позволяет запрашивать только определенные c поля ресурса:

Клиент МОЖЕТ запросить, чтобы конечная точка возвратила только указанные c поля в ответе для каждого типа путем включения параметра fields [TYPE].

https://jsonapi.org/format/#fetching -sparse-fieldsets

Поле является либо атрибутом, либо отношение в JSON: API:

Атрибуты объекта ресурса и его отношения вместе называются его «полями».

https://jsonapi.org/format/#document -resource-object- поля

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

Обратите внимание, что нет необходимости в том, чтобы схема базы данных и ресурсы, предоставляемые вашим API, были то же. На самом деле часто имеет смысл не иметь отношения 1: 1 между таблицами базы данных и ресурсами в вашем JSON: API.

Не бойтесь иметь несколько ресурсов. Часто в долгосрочной перспективе это гораздо лучше, чем иметь один ресурс со сложными объектами:

  • Вы можете включить связанный ресурс (например, dog-bodies, dog-legs, dog-furs в вашем случае) с помощью по умолчанию.
  • Вы можете автоматически сгенерировать идентификаторы для этих ресурсов на основе постоянного идентификатора родительского ресурса.
  • При наличии отдельных ресурсов у вас могут быть гораздо более строгие ограничения и более простая документация для API.
  • Вы можете уменьшить риск коллизий, поскольку можете поддерживать обновление определенных c частей (например, color атрибут dog-furs) вместо замены полного значения body ресурса dogs .

Главный недостаток, который я вижу в настоящее время - наличие нескольких ресурсов вместо одного - это ограничение на то, что вы не можете создавать или обновлять более одного ресурса в одном запросе с помощью JSON: API v1.0. Но очень вероятно, что у предстоящего v1.1 этого ограничения больше не будет. Официальный существующий под названием Atomi c Operations предлагается для этого варианта использования членом основной команды, работающим над spe c.

...