Соглашение об именовании REST API. Лучшие практики для создания или обновления ресурса. - PullRequest
Новая
       13

Соглашение об именовании REST API. Лучшие практики для создания или обновления ресурса.

0 голосов
/ 29 июня 2018

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

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

Тогда у нас есть следующие конечные точки:

  • POST / resources / для создания ресурса с необязательным external_id в полезной нагрузке
  • PUT / resources /: id для обновления ресурса

Мы хотели бы разрешить клиенту обновлять ресурс с помощью его внешнего идентификатора. Мы думали о

  • PUT / resources / create_or_update /: external_id, но мы не очень удовлетворены именем конечной точки, если не сказать больше

У вас есть идея для лучшего имени в соответствии с рекомендациями REST?

Ответы [ 2 ]

0 голосов
/ 30 июля 2018

Итак, в конце мы решили пойти на 

PUT /resources/by_external_id/:external_id

Это «наименее худший вариант», который мы придумали для обновления ресурса на основе клиентской ссылки. Пока еще можно обновить ресурс с нашей ссылкой: 

PUT /resources/:id

Как и предполагал ответ, мы могли бы действительно пойти на 

PUT /resources/:external_id
PUT /resources/:id

Но поскольку external_id и id могли использовать один и тот же формат (UUID), это могло повлиять на нашу производительность (сначала проверьте, что значение не существует в качестве id, и, если это так, проверьте, может ли это быть external_id).

Также это было предложено в одном из комментариев, но мы не хотели использовать параметр запроса.

0 голосов
/ 29 июня 2018

У вас есть идея для лучшего имени в соответствии с рекомендациями REST?

REST не волнует, какое правописание вы используете для идентификаторов ресурсов. (Демонстрация: укорачиватели URL не сломали сеть.)

Если у вас есть ресурсы в двух разных иерархиях - одна, где у вас есть полная автономия для написания, другая, где клиенты имеют некоторый контроль, тогда ... 

/09bce7a1-1f00-4bb4-8f72-8f642295a73e/:id
/8f3b9dc8-90de-48c5-aa96-a3f5a8d8e8ee/:external_id

... это отлично .

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

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

/bronze/:id
/superUltraPlatinumPlus/:external_id
...