REST является полезным для создания записи внешнего ключа из POST-запроса других ресурсов? - PullRequest
Новая
       36

REST является полезным для создания записи внешнего ключа из POST-запроса других ресурсов?

0 голосов
/ 05 мая 2018

Таким образом, у меня есть некоторые ресурсы в моем API с отношениями внешних ключей, и эти записи fk (в зависимости от проекта) не могут быть созданы, если сначала не выполняется POST для этого конкретного ресурса.

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

ПОЧТА собирается в / api / wine not / api / country

Другими словами, если я отправлю эту полезную нагрузку на ресурс Wine: 

{
  id: 79,
  name: "Bordeaux",
  country: {
      id: 76,
      code: "FR",
      name: "France"
    },
  year: "2005"
}

Он потерпит неудачу, если эта страна уже не существует. Мы не можем создать страну из этого POST, потому что мы размещаем POST для ресурса Wine, а не для Country.

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

Если у меня есть конечная точка GET, которая отражает цепочку отношений внешнего ключа 

/api/planet/country/state/city/postal_code/

и я делаю ПОЧТУ: 

/api/postal_code/

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

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

Ответы [ 2 ]

0 голосов
/ 06 мая 2018

Создание родительского ресурса при вызове нового API создания дочернего ресурса не является RESTful. Если родительский ресурс должен существовать для создания дочернего ресурса, лучший способ - следовать иерархической структуре API и генерировать исключения, если указанный родительский ресурс не найден. 

Hierarchical API structure :
/api/countries/$country_id/wines - POST

Если вы будете следовать этой структуре, потребители API будут знать, что эти родительские ресурсы должны существовать для правильной работы API клиента.

С другой стороны, если вы чувствуете, что API становится длиннее, вы можете просто выбросить исключения, когда родительский ресурс (страна) не существует.

0 голосов
/ 05 мая 2018

То, как вы это делаете, ОТЛИЧНО. Чтобы создать винный ряд, вам нужно знать все подробности этого вина.

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

А именно:

GET /api/wine/ <- Вернет все вино в базу данных против </p>

GET /api/countries/76/wine <- Вернул бы все вино только для Франции. </p>

В противном случае оба способа являются RESTful, поскольку маршрут описывает ресурс, и шаблоны для его обновления остаются прежними.

...