Метод HTTP для небольших действий, таких как (вверх) голос

Глаголы довольно просты для действий CRUD.

Каким будет правильный HTTP-глагол для выполнения только действия, что-то как upvote?

Может быть, это больше говорит о моделировании данных? Является ли upvote ресурсом или просто атрибутом? Я не уверен в этом. Скажем, он действительно модифицирует ресурс напрямую, вызывая #upvote на модели.

Например, если я поставил вопрос здесь на SO, какой глагол должен быть идеально использован для этого действия? Я частично изменяю ресурс (PATCH?), Но в то же время я не хочу указывать новое значение, поскольку я мог столкнуться с проблемами concurrency, поэтому лучше всего было бы управлять базой данных, Другими словами, мы хотим попросить сервер выполнить пошаговое действие для ресурса. Это покрывается PATCH?

Я видел аналогичный вопрос, заданный там, но их случай указывал на создание нового ресурса, просмотрев запрос на задание как объект, который будет создан. Здесь мы в одном и том же случае?

Если бы метод PATCH действительно был бы уместным, что бы он содержал?

1 ответ

Может быть, это больше говорит о моделировании данных? Является ли upvote ресурсом или просто атрибутом?

Моделирование воздействия Внедрение

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

Две возможные реализации...

1. Голоса как объекты

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

Голосование имеет состояние:

  • то, что проголосовали
  • кто голосовал,
  • когда они голосовали.
  • Было ли это голосование или пониженное голосование (в качестве примера вы упомянули SO, поэтому я включаю эту возможность здесь).

Это собственный ресурс с интересным поведением вокруг голосов

  • поддерживать правильный подсчет голосов.
  • предотвращать множественное количество голосов/вниз голосов.

Легко смоделировать с помощью REST.

Я могу POST/PUT получить новое голосование, УДАЛИТЬ предыдущее голосование, проверить мои голоса с квалифицированным GET.

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

2. Голоса как атрибут

В этой реализации мы моделируем голосование в качестве счетчика. В этом случае мы должны

  • Получить целое состояние объекта, на который проголосовали - максимизация интерфейса между клиентом и сервером

  • Обновить счетчик

  • Верните обновленное состояние - oops, кто-то уже обновил ресурс тем временем!

Теперь у сервера нет простого способа обрабатывать несколько голосов от одного и того же человека, не управляя каким-либо состоянием "сбоку". У нас также есть проблема "потерянного обновления".

Все быстро усложняется.

Окончательный совет

Решение о том, как вы моделируете что-то, должно определяться тем, что вам нужно для этой системы.

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

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

Крис

licensed under cc by-sa 3.0 with attribution.