Допустим, у вас есть сложный ресурс в REST API. У вас есть несколько флагов и атрибутов "один ко многим" на этом ресурсе (т. Е. Пользователь мог поставить ресурсу оценку от 1 до 5, или пользователь мог "лайкнуть" ресурс, пометить его как спам или проигнорировать. или вызвали установку какого-то другого состояния).
Было сделано несколько предложений о том, как лучше всего представить это в ресурсо-ориентированной архитектуре, но пока ни одно из них не порадовало меня. Итак, давайте сделаем это из краудсайдера; какие варианты вам легче всего понять? Какие варианты мы не придумали? Предположим, что API на основе OAuth, и все здесь выполняется в контексте текущего авторизованного пользователя.
Логические флаги
Вариант 1:
GET / resource / {id} / muted POST / resource / {id} / muted BODY: true POST / resource / {id} / muted BODY: false
Вариант 2:
GET / resource / {id} / без звука PUT / resource / {id} / muted BODY: true УДАЛИТЬ / ресурс / {идентификатор} / отключен
Вариант 3:
GET / resource / {id} / attributes POST / resource / {id} / attributes BODY: muted = true POST / resource / {id} / attributes BODY: muted = false
Вариант 4:
GET / resource / {id} / отключено POST / resource / {id} / mute POST / ресурс / {id} / включить звук
Атрибуты
Вариант 1
GET / ресурс / {id} / рейтинг POST / resource / {id} / rating BODY: 4
Вариант 2:
GET / resource / {id} / rating PUT / resource / {id} / rating BODY: 4 УДАЛИТЬ / ресурс / {id} / рейтинг
Вариант 3:
GET / resource / {id} / attributes POST / resource / {id} / attributes BODY: rating = 4 POST / resource / {id} / attributes BODY: rating =
Мысли? Предложения? Как с этим справились другие API? Как вы с этим справились? Обнаружили ли вы, что подобные проблемы дизайна существенно повлияли на удовлетворенность разработчиков или на простоту использования ваших API?