Нормально ли иметь обычную модель для GET и «плоскую» модель для POST с точки зрения Design REST? - PullRequest
Новая
       13

Нормально ли иметь обычную модель для GET и «плоскую» модель для POST с точки зрения Design REST?

1 голос
/ 26 мая 2019

Вопросы о возможности иметь разные модели для методов POST и GET в REST API задавались несколько раз, но я хотел бы уточнить один конкретный момент.Предположим, мы разрабатываем API для спортивных соревнований.

Модели и соответствующие ресурсы: 

1) Player
{  "id" : 2,
   "firstName" : "Nikolay",
   "lastName": "Grigoryan",
   ..... 
}

/ Players / 2

2) Турнир 

{ "id" 1,
  "name": "Some tournament",
  "date" "01.02.2019",
  .......
}

/ турниры / 1

3) Участник 

{
  "id": 2,
   "tournament": { "id" 1,
      "name": "Some tournament",
      "date" "01.02.2019",
      .......
    },
   "player": {  "id" : 2,
     "firstName" : "Nikolay",
     "lastName": "Grigoryan",
     ..... 
   }
}

/ турнир / 1 / участники / 2

Когда я запрашиваю участников определенного турнира, это удобнодостаточно иметь отдельное поле по имени игрока, связанное с полной моделью вложенного игрока со всеми доступными полями.Но когда я создаю нового участника, ситуация выглядит для меня иначе.Я бы предпочел, чтобы в качестве тела POST указывался только playerId:

/ турнир / 1 / участники

POST 

{
  ....,
  playerId: 2,
  .....
}

, но не 

{
  ....,
  "player": {
    "id": 2,
   ....
  }
}

Кажется, здесь нет необходимости иметь вложенную модель, но вместо этого достаточно только playerId, и по этой причине нет необходимости иметь вложенный объект только для хранения идентификатора.

Можно ли иметь такое упрощение модели дляPOST-запрос или они должны иметь одинаковую структуру?Вероятно, я упускаю что-то важное, делая такой вывод.Если это так, я был бы благодарен за объяснение, что именно.

Заранее спасибо.

Ответы [ 2 ]

0 голосов
/ 27 мая 2019

Один из подходов, по крайней мере, для вдохновения - взглянуть на HAL .

Если в турнире есть игроки, и это соотношение «многие ко многим», возможно, имеет смысл присоединить игроков к турниру по ссылке.

  • Чтобы получить список игроков, вы просто встраиваете ресурсы игрока.
  • Чтобы идентифицировать игроков, вы не используете их идентификатор, вы используете их URL.
  • Чтобы связать игроков с турниром, вы можете обновить ссылки.

Кроме того, я думаю, что наличие моделей, одинаковых как для получения (GET), так и для отправки (POST), является очень хорошим свойством и облегчает понимание, но также вполне нормально отказаться от этого правила, где это уместно. Я обнаружил, что особенно ситуация, когда людям часто нужен другой подход, связана с тем, что несколько ресурсов / моделей связаны друг с другом. Не существует одного элегантного способа решить эту проблему, но использование ссылок вместо идентификаторов может дать вам некоторые инструменты для общего решения, которые применимы везде.

0 голосов
/ 26 мая 2019

Можно ли иметь такое упрощение модели для запроса POST или они должны иметь одинаковую структуру?Вероятно, я упускаю что-то важное, делая такой вывод.Если это так, я был бы благодарен за объяснение, что именно.

Как бы вы сделали это как веб-сайт?выпадающий элемент управления, в котором перечислены идентификаторы, которые вы можете использовать.Клиент выберет идентификатор из списка и отправит форму.Результатом будет сообщение HTTP-запроса с идентификатором в теле запроса.

...