Каким должен быть URL-адрес отдыха для действия «Переместить участника из team1 в team2» - PullRequest
Новая
       6

Каким должен быть URL-адрес отдыха для действия «Переместить участника из team1 в team2»

0 голосов
/ 07 января 2019

Я ищу хороший URL, следуя принципам REST, чтобы "Переместить конкурента из команды 1 в команду 2

Мое первое предположение: 

/teams/{oldTeamId}/{newTeamId}/competitors/{competitorId}/move

Но это не очень похоже на REST.

Должен ли я разбить его на 2 основных вызова?

  • Удалить участника из команды1,
  • Добавить конкурента в команду2,

Должен ли я удалить некоторые данные из URL и передать их в тело?

Я действительно не знаю, что для этого сделать.

Ответы [ 3 ]

0 голосов
/ 08 января 2019

Чтобы ответить на ваши вопросы, я бы не разбивал их на два вызова, однако я бы взял некоторые данные из этого (GET) URL-адреса и поместил их в текст вашего запроса. Запрос, вероятно, будет POST или PUT (или, возможно, даже патчем), но определенно не GET, поскольку что-то действительно меняется.

Что касается решения, как насчет POST-запроса к / Transfer. В конце концов, вы (возможно) создаете новую передачу, которая берет, например, игрока, его новую команду и, возможно, старую команду.

0 голосов
/ 08 января 2019

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

Так бы

  • Сделать URL как /competitors/{competitorId}/teams
  • Сделай звонок PUT
  • Иметь тело с newTeamId и, если требуется, oldTeamId.
0 голосов
/ 08 января 2019

Подумайте, как бы вы реализовали этот API в качестве веб-сайта.

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

Обратите внимание на первый момент (также затронутый Романом Веттнером) - вашему потребителю вообще не нужно смотреть URL-адрес. Клиент знает правила обработки формы HTML, поэтому он может создать правильный HTTP-запрос, ничего не зная о домене.

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

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

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

Так что некоторые разумные варианты для цели могут быть 

/teams/{oldTeamId}

если состав команды - это самое главное. Или 

/competitors/{competitorId}

если ресурс, который описывает игрока, является самым важным.

Я действительно не знаю, что для этого сделать.

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

Вероятно, будет полезно посмотреть выступление Джима Уэббера REST: DDD In the Large , чтобы получить более четкое представление о том, как должен выглядеть ваш "REST" API.

...