Он упомянул, как вы должны справиться с этим, чтобы создать ресурс для всех 3 пользователей.Ресурсы дешевы и бесконечны (вы можете заработать столько, сколько захотите), поэтому используйте их.Итак, создайте этот ресурс и в одну операцию поместите его обновление статуса.
...
Как бы я создал конечную точку / ресурс отдыха, поскольку Джим Уэббер предполагает обрабатывать эту операцию?
Основное правило здесь: Как бы вы сделали это в Интернете?Поскольку REST - это всего лишь обобщение модели взаимодействия, которой Интернет позволил расти до своего сегодняшнего размера, тот же концепт, который доказал свою эффективность в Интернете, может (и должен) использоваться в архитектуре REST.
Чтоэто группа ресурсов на самом деле ?!Если вы думаете о большинстве спортивных мероприятий, в которых играют в командах, таких как футбол или тому подобное, почти все игроки могут быть разделены на определенные группы.Т.е. игроки Team A и игроки Team B или all defensive players или all attacking players.Каждый из игроков является своим собственным ресурсом, но каждая из доступных групп является своим собственным ресурсом, и мы могли бы также дать ему имя.Далее можно поговорить о группе, а не об отдельном игроке.Что позволяет нам вместо того, чтобы ссылаться на всех игроков по отдельности, включать их всех в одно короткое утверждение.Такое утверждение, как «Team A побей дерьмо из Team B», скорее всего, подсчитает, что каждый из игроков на Team A играл лучше, чем их коллеги в команде противника.
Сейчастолько вопрос предоставления клиентам набора инструментов для группировки ресурсов.На типичной HTML-странице вы можете иметь представление таблицы всех активных футболистов этого сезона во всех командах с флажком для выбора определенных игроков и некоторым элементом управления, таким как кнопка отправки, позволяющая создать группу длявыбранные игроки.Поддерживающая HTML-форма содержит не только фактический набор данных, из которого можно выбрать отдельных игроков, и кнопку отправки, но также целевой URI, на который должен быть отправлен запрос, а также метод запроса для использования.HTML по умолчанию использует application/x-www-form-urlencoded в качестве формата представления для отправки данных на сервер, который знает, в зависимости от вызванной конечной точки, используемой операции HTTP и типа полученного носителя, как обрабатывать данные соответствующим образом.
Какновый ресурс будет создан как следствие предыдущего запроса на группировку, сервер ответит кодом ответа 201 Created и заголовком HTTP Location, значением которого является URI, указывающий местоположение, в котором доступна вновь созданная группировка.Теперь клиент может автоматически перенаправляться на этот URI или использовать возвращенный URI для вызова дальнейших операций с этим ресурсом.Поскольку модель предметной области (и, вероятно, должна) не должна соответствовать модели ресурса или доступности, каждый из ресурсов отдельного игрока, а также командный ресурс могут использовать одни и те же записи базы данных для представления данных клиенту.При обновлении одного ресурса (либо отдельного игрока, либо команды в целом) эта операция также может повлиять на другие ресурсы.
Если вы посмотрите на определение PUT в спецификации HTTP, вы можете прочитать что-то вроде этого:
Запрос PUT, примененный к целиресурс может иметь побочные эффекты на других ресурсах.
Из-за этого побочного эффекта обновление, выполняемое через PUT, может привести к чему-то похожему на частичное обновление:
Частичные обновления содержимого возможны путем нацеливания на отдельно идентифицированный ресурс с состоянием, которое перекрывает часть большего ресурса, или с использованием другого метода, который был специально определен для частичных обновлений (например, метод PATCH, определенный в RFC5789 ).
Т.е. при обновлении Player 1 из Team A с помощью PUT в качестве побочного эффекта создается частичное обновление состояния Team A какон просто использует те же данные, которые модель данных предоставляет для этого конкретного игрока.
Для достижения той же функциональности в архитектуре REST, как упомянуто ранее, те же концепции предоставления клиенту структурированных данных позволяют ему выбирать подмножество и выполнять операции с этим подмножеством, такие как создание нового ресурса для них. выбранные элементы, должны быть использованы. В отличие от Интернета, где доминирует HTML, поддерживаемые типы мультимедиа могут сильно различаться в архитектуре REST. Здесь согласование типа контента является очень важной частью, поскольку это позволяет серверу выбирать наиболее подходящий формат представления, поддерживаемый клиентом. Вместо использования собственных форматов представления следует использовать стандартизованные форматы, чтобы повысить вероятность того, что клиенты, не находящиеся под вашим контролем, смогут взаимодействовать с вашей системой. Несмотря на то, что в настоящее время предпринимаются усилия по внедрению медиа-типов, поддерживающих клиентов с обратной связью с клиентами в форме форм, аналогичных тем, которые используются в HTML, де-факто стандартного представления форм, за исключением HTML, не существует, но он широко принят. Есть несколько особенно подходов, основанных на JSON, таких как hal-формы , halo + json , Ion или Hydra , в хотя, как уже упоминалось, ничего, что действительно широко используется в производстве,
Поскольку ваше точное намерение состоит в том, чтобы обновить кучу ресурсов атомарно, вы также можете использовать PATCH и здесь, без необходимости создавать новые ресурсы, так как PATCH определен для выполнения всех инструкций атомарно - либо все удастся, либо вообще ничего В спецификации PATCH определяется аналогично пониманию исправления в разработке программного обеспечения, имея последовательность инструкций, которые должны применяться к ресурсу для преобразования его в желаемый результат. application/json-patch+json - это формат представления, который очень близок к фактическому определению, тогда как application/merge-patch+json использует его совершенно по-другому, определяя применяемые правила по умолчанию, в зависимости от того, содержался ли запрос измененное или обнуленное значение поля. Поскольку последний формат представления может работать только на одном ресурсе, первый формат представления может использоваться для пакетного обновления. Благодаря прямому нацеливанию на ресурс коллекции, Указатели JSON могут использоваться для непосредственного обращения к соответствующим полям подресурсов в этой коллекции.
Чтобы избежать потери данных с помощью операций PATCH, из-за промежуточных обновлений между извлечением самого последнего состояния, вычислением необходимых шагов для применения и отправкой запроса в API, следует использовать оптимистический подход к блокировке, который достигается посредством условных запросов , таких как ETag .
Несмотря на то, что исправление дает вам возможность применять изменения атомарно, я чувствую, что группировка ресурсов, если они естественным образом образуют группу, например, в примере «игрок - команда», кажется более распространенной и использует модель взаимодействия, предложенную REST. тоже лучше ИМО.